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General Chairman’s Message 


On behalf of the NASA Langley Formal Method’s Team, I welcome you to Lfm2000, the Fifth 
NASA Langley Formal Methods Workshop. When the series began in 1990, attendees and 
presenters were limited to people directly involved in NASA Langley’s nascent formal methods 
program. Subsequent workshops in 1992 and 1995 also restricted attendance to invited people. With 
the 1997 workshop, we removed attendance restrictions, and also issued an international call for 
papers. We continued this approach for Lfm2000. 

We believe that the program has something to offer just about everyone, from those interested 
in the theoretical aspects of formal methods to those interested in the practical application of formal 
methods to help solve industrial problems. We hope that you agree, and that your time at the 
workshop is both interesting and useful to you. 

The paper copy of the proceedings contains the papers selected by the program committee for 
presentation. The CD contains Portable Document Format (PDF) and (in many cases) PostScript 
versions of the papers, supplementary information from some authors, tutorial slides and 
supplementary material, and information about the NASA Langley formal methods program. Much 
of this material will also be available on the world- wide web at the Lfm2000 web site at 
<http://shemesh.larc.nasa.gov/fm/Lfm2000>. 

Once again, welcome! I look forward to meeting you during the workshop. Please let me 
know if there is anything that I can do to help you while you are here. 



C. Michael Flolloway, Lfm.2000 General Chairman 
email : <c. m. hollo way@larc. nasa. gov> 

postal address: Mail Stop 130, NASA Langley Research Center, Hampton VA 23681-2199 
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Program Committee Chairman’s Message 


Welcome to Lfm2000! We are pleased to be able to bring you a strong program of research 
papers and experience reports. This year we added a tutorial track to complement the research 
presentations. We were fortunate to receive several excellent tutorial proposals from some rather 
accomplished presenters, so we hope you find this a valuable addition to the workshop format. 

Following the organization we adopted at Lfm97, our previous workshop, we drew the bulk of 
the Lfm2000 program from refereed submissions. We received 37 paper submissions, from which 
17 papers were selected for presentation at the workshop and publication in the proceedings. Each 
paper received at least three reviews, either by members of the Program Committee or by outside 
referees, hi addition to selected papers, we invited several speakers to give talks on trends and 
perspectives, including presentations on ongoing NASA activities and interests. 

Submissions to Lfm2000 showed a continued strong interest in the area of applied formal 
methods. The diversity of submissions increased somewhat over our previous workshop in 1997. 
Also evident in the accepted papers was a decided shift toward lighter weight methods and the 
algorithmic analysis techniques typified by model checking. This trend reflects the growing interest 
in finite state analysis that has been seen at other research meetings. It is too soon to tell, however, 
whether this growth conies at the expense of interest in the deductive analysis methods. Perhaps 
by the time of our next workshop we can gauge the community's directions more definitively. 

I would like to thank members of the Program Committee for all then hard work in reviewing 
and selecting papers for this year's program. Thanks are also due to the auxiliary referees who 
contributed their time. Finally, let me thank the Organizing Committee for helping to give shape to 
the finished product. 

I hope you find this a rewarding meeting. We welcome any feedback you might wish to 
provide so that our next offering will be better still. 


Ben Di Vito, Lfm2000 Program Chair 
email: <b.l.divito@larc.nasa.gov> 

postal address: Mail Stop 130, NASA Langley Research Center, Hampton VA 23681-2199 
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Abstract 


Designers often cite unfamiliar notation as one obsta- 
cle to wider acceptance of formal methods. Formal- 
izations of design notations, such as timing diagrams, 
promise to bridge the gap between design practice 
and formal methods. How to use such formaliza- 
tions effectively, however, remains an open question. 
Developing new tools around design notations might 
provide better support for reasoning at the level of 
the preferred notations. On the other hand, trans- 
lating the formalizations into established notations 
enables leveraging off of existing tools. This decision 
of whether to treat design notations as interfaces de- 
pends largely on computational tradeoffs. This paper 
explores this issue in the context of specifying proper- 
ties for automata-theoretic verification using timing 
diagrams. Automata-theoretic algorithms perform a 
tableau construction to convert properties into Bfichi 
automata. We contrast direct compilation of timing 
diagrams into Bfichi automata with an approach that 
uses linear-time temporal logic (LTL) as an interme- 
diate language during translation. Direct compila- 
tion generally produces much smaller automata and 
scales significantly better with variations in key tim- 
ing diagram parameters. We attribute this to combi- 
nation of a correspondence between timing diagrams 
and weak automata and certain shortcomings in cur- 
rent LTL-to-Bfichi algorithms. 


1 Introduction 

Computer-aided verification uses techniques from 
logic and mathematics to prove whether design mod- 
els satisfy certain properties. Although these tech- 
niques have been used successfully on several siz- 
able examples, many designers are reluctant to adopt 
them. One frequently cited problem is the notation 
that verification tools employ [9]. Verification tech- 
nologies are grounded in formal logic. Accordingly, 
most tools use their underlying logics as property 
specification languages. For example, model checkers 
employ temporal logics, while theorem provers use 
various flavors of higher-order logic. In contrast, de- 
signers use a wide array of notations, including circuit 
diagrams, timing diagrams, state machines, VHDL 
and Verilog. This rich array of representations, some 
of them diagrammatic, stands in stark contrast to the 
monolithic textual logics of verification tools. 

Bridging this gap requires verification tools that 
support notations that are more familiar to designers. 
One approach is to develop new tools and algorithms 
which support design notations directly [3]. Another 
is to create interfaces from design notations to exist- 
ing languages [1, 8]; this leverages off existing tool 
development efforts. 1 Which approach yields more 
efficient algorithms is an open question. There may 
exist algorithms for model checking timing diagrams, 
for example, that outperform those for the temporal 

'Many efforts (other than those cited) are ad-hoc, however, 
because they do not formalize the design notations. 



logics into which we might translate timing diagrams. 
Understanding these tradeoffs requires studies of the 
logical nature of design notations and their role in 
verification algorithms. 

This paper explores these tradeoffs in the context 
of compiling timing diagrams to Biichi automata. 
Automata-theoretic verification tools, which support 
linear-time logics such as LTL, operate at the level 
of automata. Using such tools on timing diagrams 
requires algorithms for compiling timing diagrams to 
Biichi automata. We compare two compilation meth- 
ods, one which compiles timing diagrams directly into 
Biichi automata and one which translates timing di- 
agrams into LTL and then uses existing algorithms 
for compiling LTL into Biichi automata. Our results 
show that the direct approach produces far smaller 
machines even on simple examples. This appears due 
to a combination of structural properties of the au- 
tomata that capture timing diagrams and shortcom- 
ings in existing LTL-to-Biichi translation algorithms. 

Section 2 presents an overview of automata- 
theoretic verification. Section 3 describes timing dia- 
grams and linear-time temporal logic, the two nota- 
tions used in this paper. Section 4 presents our algo- 
rithms for compiling timing diagrams into LTL and 
Biichi automata. Section 5 presents an experimental 
comparison of the two approaches to obtaining Biichi 
automata from timing diagrams. Section 6 discusses 
the experimental results and their implications for 
verification research. 

2 Automata-Based Verification 

Automata-theoretic verification views both systems 
and properties as finite-state automata [12, 14]. Ver- 
ifying whether a system satisfies a property is analo- 
gous to asking whether the property automaton ac- 
cepts the language generated by the system. In other 
words, for a system S and a property P, verification 
reduces to a language containment question of the 
form C(S) C £(P), where £ denotes the language of 
an automaton. This is equivalent to asking whether 
C(S) fl £{P) = 0. In practice, automata-theoretic 
verification tools implement the latter; they intersect 
the automaton for the negation of the property with 


the automaton for the system and check whether the 
language of the product automaton is empty. 

Many other verification problems can be expressed 
in terms of operations on languages. Property de- 
composition is one example. Properties often prove 
intractable to verify because they require too many 
computational resources, such as time or memory. 
One can approach such cases by decomposing the 
original property into a set of simpler properties, each 
of which is tractable to verify. If the simpler prop- 
erties collectively imply the original property, then 
verifying each simple property independently is suf- 
ficient to verify the original property. To support 
decomposition, verification tools must check whether 
one set of properties implies another. If a property P 
is decomposed into properties Pi , . . . , P* , this check 
reduces to £{P) C £(P\) fl . . . fl C(Pk). 

Both of these checks are decidable for a large class 
of verification problems. Implementing them requires 
procedures to obtain two kinds of automata: those 
that accept the language of a given property and 
those that accept the language of the negation of a 
given property. This project investigates both prob- 
lems in the context of timing diagrams. 

3 Timing Diagrams and LTL 

3.1 Timing Diagrams 

Timing diagrams express patterns of value changes 
on signals. In addition, they express precedence and 
synchronization relationships between changes, and 
timing constraints between changes. As part of our 
overall research program, we have developed a logic 
of timing diagrams [5]. This section describes the 
portion of the logic that is relevant to this paper. 

Figure 1 provides a sample timing diagram that 
will serve as our running example. Variables a, b , 
and c name boolean-valued signals. To the right of 
each name is a waveform depicting how the variable’s 
value changes over time. For example, b transitions 
from low to high, then later returns to low. We inter- 
pret low as logical false and high as logical true. Ar- 
rows indicate temporal ordering between transitions; 
for this paper, we assume that timing diagrams spec- 
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Figure 1: A timing diagram and an illustration of its semantics. 


ify a total ordering on the transitions through arrows 
and ordering within waveforms. Annotations of the 
form [/,«] on the arrows indicate lower and upper 
bounds on the time between the related transitions; l 
is a natural number and u is a natural number or the 
symbol oo. 2 The labels at the bottom, referred to as 
time points , are for explanatory purposes and are not 
part of the timing diagram; intuitively, there is one 
time point for each transition in the diagram, plus one 
for each of the endpoints of the diagram. The portion 
of the diagram between each pair of time points is an 
interval, interval Ij spans from time point pj to Pj+i- 

Since timing diagrams express sequences of values 
of variables over time, an appropriate semantic model 
for them must do the same. Formal languages, which 
are sets of sequences over a given alphabet, suggest 
such a model. Our semantics considers finite or infi- 
nite words over an alphabet consisting of all possible 
assignments of boolean values to the names labeling 
waveforms. Intuitively, a word models a timing di- 
agram when the transition patterns in the diagram 
reflect the changes in values assigned to names in the 
word. A timing diagram language is any set of words 
such that every word in the set models the timing di- 
agram. This paper provides an intuitive description 
of the semantics; the full details appear elsewhere [5]. 

Consider the timing diagram and word in Figure 1. 

2 The full logic supports richer bounds with variables [5]. 


The word appears in tabular form: the waveform 
names label the rows and the indices into the word 
label the columns. Each cell in the table indicates 
the value on the corresponding signal at the corre- 
sponding index. Symbols 0 and 1 denote false and 
true, respectively. The two lines directly beneath the 
table indicate two separate assignments of indices to 
time points, as explained shortly. 

Intuitively, the semantics walks along a word look- 
ing for indices that satisfy each time point. An index 
satisfies a time point if the values assigned to each 
variable correspond to those required by the transi- 
tions at the time point; satisfaction relies on both 
the current index and its immediate successor. For 
example, in Figure 1, time point pi contains a rising 
transition on signal a; index d satisfies p\ if d assigns 
value 0 to a and index d + 1 assigns value 1 to a. 

For the word and timing diagram in Figure 1, in- 
dex 0 satisfies the rising transition on a. The walk 
now searches for an index containing a rising tran- 
sition on b ; index 1 meets this criterion. When the 
walk locates the rising transition on c in index 2, the 
semantics checks whether the located indices respect 
the timing constraint between the transitions on b 
and c. The two transitions occurred one index apart, 
which is valid. Continuing the walk locates time point 
Pi at index 3 and time point p§ at index 5. The first 
row below the table shows this assignment of time 



points to indices. The second row shows another as- 
signment, starting from index 4. This walk fails, be- 
cause the distance between the indices satisfying p 2 
and P4 is larger than 3, the maximum allowed by the 
time bound on the arrow from the rising transition 
on b to the falling transition on c. The semantics al- 
ways checks the first occurrence of a transition that 
it finds once it begins searching for it. The formal 
semantics [5] defines this precisely. 

Three other aspects of our semantics are relevant: 

• Timing diagrams express assume-guarantee re- 
lationships; we specify some prefix of the time 
points as the assume portion , and only check the 
entire diagram when we locate indices satisfying 
the assume portion. In our example, taking the 
assume portion to be time points po and pi , we 
would search for the entire diagram only if an 
index reflects a rising transition on a. 

• We view timing diagrams as invariants, mean- 
ing that we attempt to satisfy the timing dia- 
gram from every index which satisfies the assume 
portion. In our example, we would search from 
every index containing a rising transition on o, 
namely indices 0 and 4, as in our demonstration. 

• A parameter over the timing diagram indicates 
which segments of waveforms should be matched 
exactly within words; the rest are treated as 
don’t-cares. Segments to be matched exactly 
are called fixed-level constraints. For example, 
we could require a to remain high until the rising 
transition on c by putting a fixed-level constraint 
on a between time points p\ and p 4. 

Index satisfaction and fixed-level constraints are 
simply constraints on the values of particular vari- 
ables; each constraint is a conjunction of literals cap- 
turing the values required on each variable. A fixed- 
level constraint requiring a to be low and c to be high 
would be the conjunction -mAc. The actual conjunc- 
tions are irrelevant to the algorithms in the rest of the 
paper. We therefore describe our algorithms in terms 
of the following symbols: 

• Af. the fixed-level constraint in interval fi. 


• APi i n i t : the first index required to satisfy the 
transition at time point i. 

• A P,: the second index required to satisfy the 
transition at time point i. 

• Tp. The conjunction APa n n A X.4P,. which uses 
the temporal logic next-time operator to capture 
the requirements for satisfying a transition. 

3.2 Linear-time Temporal Logic 

Like timing diagrams, linear-time temporal logic de- 
scribes patterns of changes in variables over sequences 
of assignments. LTL is a propositional temporal 
logic [13], defined relative to a finite set of propo- 
sitions V. The formulas of LTL include V and are 
closed under unary operators -1 and X (next), and bi- 
nary operators V and U (until). Intuitively, Xip says 
that ip holds in the next state, while (fillip says that <p 
holds in every state until i\> holds, and rp eventually 
holds. Other temporal operators, such as G (some- 
thing holds in all states) are defined in terms of U. 
Formally, LTL formulas are given semantics relative 
to sequences of assignments to V. An infinite word 
£ = X0X1 ... is a sequence of elements of 2 V . £, de- 
notes the suffix of £ starting at a:,. A word £ models 
formulas according to the following definition: 

• £ |= q iff q G Xo, for q e V, 

• p |= iff not £ |= <p, 

• £ |= <p V ip iff P |= P or p |= ip, 

• p |= Xip iff £1 |= tp, 

• p |= p(hp iff there is an i > 0 such that £1 \= ip 
and pj |= <p for all 0 < j < i. 

A language models a formula iff every word in the 
language models the formula. 

4 Tableau Constructions 

As discussed in Section 2, automata-theoretic verifi- 
cation tools compile formulas into Biichi automata. 
As LTL model checking uses the automata-theoretic 
framework, several algorithms exist for compiling 



LTL formulas into Biichi automata [2, 7]; these algo- 
rithms use a technique called tableau construction. 
The timing diagram semantics effectively define a 
Biichi automaton accepting a timing diagram lan- 
guage. Thus, we have two possible routes to compil- 
ing timing diagrams into Biichi automata, as shown 
in the diagram below: compile the timing diagram 
directly to a Biichi automaton which corresponds to 
the semantics, or translate the timing diagram into 
LTL and use existing LTL-to-Biichi algorithms. The 
second approach reflects the view of timing diagrams 
as visual interfaces for temporal logics [1]. 

our existing 

translation algorithm 

TD LTL ^ Biichi 

s'"' 

semantics 

We would like to compare the Biichi automata aris- 
ing from these two approaches. Is one substantially 
larger than the other? Size is important because this 
form of verification computes the cross-product of 
the automata representing the design and the prop- 
erty. Does one approach yield a Biichi automaton 
that is more amenable to verification than the other? 
Some verification heuristics work only on property 
automata with particular structural features. An- 
swers to these questions help determine whether ver- 
ification tools can safely treat timing diagrams as in- 
terfaces to LTL expressions without having an ad- 
verse effect on the verification process. 

Our translations from timing diagrams to each of 
LTL and automata rely on the same intermediate rep- 
resentation, a form of abstract state machine. States 
in this machine record which interval they correspond 
to, their transitions to other abstract states, and a 
set of labels which provide information to the back- 
end tools. The abstract machine captures one pass 
or walk of the timing diagram semantics, leaving the 
backend tools to support repetitions as necessary. 

4.1 Generating the Abstract Machine 

Generating an abstract machine from a given tim- 
ing diagram proceeds in two steps. First, we need to 



Figure 2: Step distribution tables for the example 
timing diagram. 


calculate the possible numbers of steps that a valid 
word can spend in each interval. We partition the 
time points into cells such that time points i and j 
are in the same cell iff there is an arrow spanning 
intervals i and j: for our example timing diagram, 
the cells are {0}, {1}, {2,3}, {4}, and {5}. For each 
cell, we generate a table showing the possible combi- 
nations of steps allowed in each interval. Each row 
of the table provides one distribution of the time al- 
lowed by the bounds across the corresponding inter- 
vals; if the total amount of time is a lower bound, 
the value in the last column of the table is marked 
with a + . Figure 2 shows the tables for our example 
diagram. They say that a valid word must contain at 
least one letter in the first interval (1+ in the first ta- 
ble), some combination of 2 or 3 letters in the interval 
between time points 2 and 4 (the middle table), and 
at least two letters in interval I 4 . We generate the 
tables using a straightforward procedure for calculat- 
ing distributions across variables. We then eliminate 
distributions that violate some timing constraint; the 
example diagram, for example, allows the arrow from 
the rising transition on b to the rising transition on 
c to last 3 steps, but doing so would violate the con- 
straints of the edge from the rising transition on b 
to the falling transition on c. The tables in Figure 2 
contain no row allowing 3 steps in interval / 2 - 

Next, we generate abstract states from the cells 
and tables. Each abstract state contains the time 
point it corresponds to, a set of transitions to other 
abstract states, and a set of labels (which we de- 
scribe shortly). We generate a final state (labeled 
final) with a self-transition; this corresponds to the 
maximal time point. We also generate two abstract 
states with transition to the final state for each time 
point in the assume portion: one labeled PM for pat- 







Figure 3: The abstract machine for the example timing diagram. 


tern mismatches and one labeled CV for constraint 
violations; these capture violations of the timing dia- 
gram patterns in the assume portion. The generation 
method processes the cells in reverse order. For each 
cell, we generate a set of states, designating one as the 
initial state for the cell, as follows. If there is no table 
for the cell, we generate one abstract state with two 
transitions: one to itself and one to the initial state 
for the cell containing the next time point. If the time 
point is in the assume portion, the abstract state also 
contains a transition to the pattern-mismatch state 
for the corresponding time point. 

If there is a table for a cell, we must generate se- 
quences of states that count steps in the intervals as 
indicated in the tables. Rather than generate these 
sequences independently, however, we share states at 
the prefixes of the sequences when possible. All se- 
quences will share at least one common prefix state; 
this is the initial state for the cell. For the exam- 
ple timing diagram, all rows for cell {2, 3} require at 
least one state in interval 2. Each state contains a 
transition to the next state in the sequence; states 
in common prefixes may have transitions to multiple 
suffixes. In addition, if the last entry in a row is an- 
notated with +, the final state in the sequence for 
the row contains a self-loop. If the cell is in the as- 
sume portion, each state also contains transitions to 
the pattern-mismatch and constraint- violation states 
for the corresponding time points. Figure 3 shows 
the abstract machine corresponding to our example 
timing diagram. We have explained the structure of 
this machine; we now describe the labels. 

Each state corresponding to a time point in the 


assume portion receives the label assume. For each 
state other than the final, pattern-mismatch, and 
constraint-violation states, we add all labels from the 
following list for which the state satisfies the indi- 
cated constraints relative to the structure of the tran- 
sition system; let B be a state at time point pp. 

• start: no other state for time point Pi reaches B\ 

• end: B reaches no other state for time point pf, 

• can: B has successors for time points Pi and Pi+i ; 

• cannot: all successors are for time point p, t ; 

• must: no successor is for time point Pi. 

The labels start and end indicate the first and last 
states for each corresponding time point; can, cannot, 
and must indicate whether a word can, cannot, or 
must advance to the next time point from this state. 
While some of these labels have overlapping meaning 
(all must states are end states, for example), no two 
labels are equivalent. 

4.2 Generating LTL 

This section generates an LTL formula corresponding 
to one pass of the timing diagram semantics. Wrap- 
ping the formula in LTL operator G yields the invari- 
ant formula. The procedure follows the structure of 
the abstract machine. There are two steps in gener- 
ating the LTL for a given abstract state: generating 
the propositional expression that captures the fixed- 
level constraints for the state and connecting this ex- 
pression with those for other states using temporal 
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Figure 4: LTL generated for example timing diagram 


operators. The expression for a state is the fixed- 
level constraint Aj; if the state is the first or last in 
a time point, we conjoin Ai with AT) or AF) + | j n ; t , 
respectively. The temporal operators are based on 
the transition structure of the abstract machine. 

Formally, procedure GenLTL(P) produces the LTL 
for abstract state B as follows, where R is the tran- 
sition relation of the abstract machine. For abstract 
states B without self-loops, GenLTL(B) produces 

Ai A Ti A \J X(GenLTL(B')). 

B'£R{B) 

For abstract states B with self loops, GenLTL(B) is 
[{Ai A -iTi) U {Ai A Ti A \/ X(GenLTL(B')))]. 

B'eR(B) 

The Tj’s require the expression to match the first 
available transition to the next time point. To handle 
the assume portion, the algorithm generates LTL for 
the restriction of the abstract machine to the assume 
portion and forms an implication from this formula to 
the LTL for the entire diagram. This follows the in- 
tuitive semantics of timing diagrams. Figure 4 shows 
the resulting LTL for our running example. The con- 
trast between the formula and the original timing dia- 
gram motivates designers’ frustrations with common 
verification notations. 

4.3 Generating Biichi Automata 

A Biichi automaton is a tuple ( Q,qo,R,L,T ) where 
Q is a set of states, qo is the initial state, R C Q x Q 
is the transition relation, L indicates propositions 


that are true in each state, and T C Q is a set 
of fair states. The abstract machine resembles a 
Biichi automaton; however, it does not capture a 
timing diagram because it does not enforce match- 
ing the first occurrences of transitions. The Biichi 
automaton states enforce this by examining proposi- 
tions APj + ii n it and .4T i+ i , which indicate when tran- 
sitions should occur. These states also refer to the 
fixed-level constraint Aj. 

Monitoring APj + i; n ; t and AP i+ \ implies that an 
abstract state can expand into four Biichi states (Aj 
must hold in each; the pattern-mismatch states ac- 
count for when Aj does not hold). The number may 
be more or less depending on the abstract state’s 
labels. Regardless of the labels, only a few com- 
binations of propositions arise in practice. Table 1 
(left) lists templates of the generated Biichi states. 
For each state, we list the propositions that are true 
in that state and a set of labels. These labels are 
not part of the Biichi automaton; the algorithm uses 
them to create transitions between states. The labels 
can be divided into two sets, depending upon whether 
they contain this; we explain the distinction shortly. 

The Biichi automaton generator converts abstract 
state B into Biichi automaton states b \ , . . . , b m in 
two steps. First, it creates the template states indi- 
cated in Table 1 (right). Second, it adds the outgoing 
transitions for each bk ■ These outgoing transitions 
depend on P’s labels and whether bk outputs propo- 
sition APj_|_ii n i t . This proposition matters because 
it indicates that bk could recognize the start of the 
next time-point. Any transitions from bk to states 
outputting proposition APj + i must be to states cor- 
responding to the next time-point. 




Propositions 

Incoming Labels 

Si 

A{ , |-ii n it) APi+\ 

this-tp, this-tp-trans 

s 2 

A-i, ~'APj t + liniti APi+ 1 

this-tp, this-tp-trans 

S3 

A%, AP j-|-li n it 5 —*APi+ 1 

this-tp, this-tp-no-trans 

S4 

Ai-, —'APi+ linit? —'APi-^. 1 

this-tp, this-tp-no-trans 

S 5 

Ai, ^-^i+linit> AP{ 

tp-start 

S e 

A%, “ i APi+ijjift , AP{ 

tp-start 

s 7 

-'APi 

cv-no-trans 

Ss 

Ai, APi 

cv-trans 

s 9 

~>Ai 

pv-this 

S10 

-'Ai, APi 

pv-on-trans 

Sn 

-'Ai, -■ APi 

pv-this-no-trans 

S12 


final 


Type 

Start? 

States 

cannot 

yes 

s 5 ,s 6 

cannot 

no 

Si, S 2 , S3, s 4 

must 

yes 

S 5 plus this-tp label 

must 

no 

Si, S3 

can 

yes (ex. p 0 ) 

Si, S 2 , S3, Si, s 5 , s 6 

can 

no or po 

Si, s 2 , s 3 , Si 

CV 


S 7 ,Ss 

PM 


Sg, S 10 , S 11 

final 


S12 


Table 1: Tables defining translation of abstract states to Biichi states. 


Type 

Next 

Init? 

Outgoing Labels 

can 

yes 

tp-start, this-tp-no-trans 
pv-this-no-trans, pv-on-trans 

can 

no 

this-tp pv-this 

cannot 

yes 

this-tp-no-trans, pv-this, cv-trans 

cannot 

no 

this-tp, pv-this, cv-trans 

must 


tp-start, pv-on-trans, cv-no-trans 


Table 2 : Determining transitions between states. 


More specifically, we connect the transitions for bk, 
generated from abstract state B , according to the fol- 
lowing algorithm: Let ci,...,c„ be the states that 
expand all successors of B in the abstract machine. 
Let hu be the set of labels for bk according to Ta- 
ble 2. For each cj, add a transition from bk to Cj iff 
Cj comes from the same (resp. a different) time point 
as bk and the incoming labels for cj contain some 
this (resp. non-this label) label from hk ■ The fair 
states consist of the state labeled final and all states 
expanding abstract states labeled assume. 

As an example, let B be the rightmost abstract 
state for time point 4 from Figure 3. The following 
diagram shows the expansion. The four states in the 
dashed box correspond to B. Table 1 (right) tells 
us to create these states because B matches the sec- 
ond can line. State S$ expands the abstract state for 


time point 5; we include it to illustrate the transition 
connection procedure. 



Tables 1 and 2 determine the outgoing transitions 
for each state in the dashed box. For example, S 3 
matches the first row in Table 2 because B has label 
can and S 3 outputs AP i+ ii n i t . Thus, it needs a tran- 
sition to each state in the dashed box with incoming 
label this-tp-no-trans (states S 3 and 54 by Table 1 
(left)) and each state outside the box with label tp- 
start (state S 5 ). We ignore the pv labels since there 
are no PM states for time points 4 or 5. A similar 
process yields the transitions for the remaining states. 

Having presented algorithms for translating timing 
diagrams to both LTL formulas and Biichi automata, 
we need to check whether the derived formulas and 
automata correspond on a logical level. Given a tim- 
ing diagram D , let Dltl and Dba be the formula 
and automaton derived for D, respectively. We have 
proven that jC(Dba) models Dltl according to LTL’s 
semantics. As a sanity check on this result, we con- 
structed an LTL formula capturing the structure of 
Dba and compared it to -Dltl using an LTL equiv- 
alence checker [10]. These formulas are equivalent 






for a large test suite of timing diagrams, including 
those used in our experiments. Thus, we have high 
confidence in the correctness of our translations. 

5 Experimental Results 

This section compares our Dba automata to those 
derived from Dltl using an existing LTL-to-Buchi 
translation algorithm [2] with respect to their num- 
bers of states. We do not report running times be- 
cause the algorithms have been implemented in dif- 
ferent paradigms, which reduces the value of such 
figures; in practice, the direct translations were sub- 
stantially faster than the LTL-based translations. We 
report two groups of experiments. In the first, we 
generate automata for one pass of the timing diagram 
semantics. In the second, we generate automata for 
the negation of timing diagrams when treated as an 
invariant. The latter is required to model check tim- 
ing diagrams using an automata-theoretic approach. 

When comparing how each approach scales with re- 
spect to a given timing diagram, there are two classes 
of parameters to consider: the values of the lower and 
upper time bounds on the edges and the size of the as- 
sume portion. While the bounds certainly affect the 
size of the resulting automata, we conjecture that the 
size of the assume portion will be more significant. 
Consider the structure of Dltl- As Figure 4 shows, 
the subexpression for the assume portion appears on 
both sides of the implication in the LTL formula. 
LTL-to-Buchi algorithms normalize formulas before 
translation: the normalization process will destroy 
the similarities between the two copies of the assume 
portion. Our timing diagram to automaton algo- 
rithm, in contrast, translates the assume portion only 
once. Our experiments use Daniele, Giunchiglia, and 
Vardi’s LTL-to-Buchi algorithm, which yields more 
compact automata than other algorithms [2]. 

5.1 Accepting Timing Diagrams 

As an initial experiment, consider a very simple dia- 
gram with an empty (trivial) assume portion. The 
table shows the number of states in the D ba au- 
tomaton (column “Dba”) and the number of states 


obtained compiling Dltl to an automaton (column 
“via Dltl”)- The first two columns vary the bounds. 
Each automaton sees constant growth with respect to 
increases in the time bounds. This supports our hy- 
pothesis that the magnitude of the bounds does not 
yield significant differences between the two trans- 
lation algorithms. Similar experiments on diagrams 
with more transitions show similar results: while the 
magnitude of the constant difference between the two 
machines increases slightly on these examples, the 
differences are still small constants when the assume 
portion is empty. 


/ u Dba via Dltl 



The picture changes dramatically as the assume 
portion grows beyond one transition. Consider a. di- 
agram with four transitions, as shown below. Each 
group of three experiments uses the same bounds and 
varies the assume portion size. The difference be- 
tween assume portion sizes of one and two is substan- 
tial in each group. Furthermore, as the bounds in the 
assume portion grow, this difference appears to grow 
exponentially. Growth of each automaton still ap- 
pears constant across experiments with the same as- 
sume portion size and varying bounds. This supports 
our hypothesis that the size of the assume portion is 
more important than the size of the bounds. The size 
of the bounds appear to matter more in the assume 
portion than in the non-assume portion. This makes 
sense, as the LTL-to-Buchi algorithm negates the as- 
sume portion to construct the automaton. This nega- 
tion creates many disjunctions, which lead to branch- 
ing and extra states in the LTL-to-Buchi translation. 
The larger the bounds, the more disjunctions result 
from the assume portion. 





The LTL-to-Biichi approach produces smaller au- 
tomata than our approach in some cases when the 
assume portion is empty. We believe this is due to 
a slight difference in how we handle relationships be- 
tween the symbolic propositions (Aj, etc) in the two 
algorithms that would favor the LTL-based approach. 

5.2 Rejecting Timing Diagrams 

Model checkers require an automaton accepting the 
negation of a property. Even though we cannot draw 
the negation of a timing diagram as a timing dia- 
gram, we can still produce an automaton that ac- 
cepts all words that fail to satisfy the timing diagram. 
This section compares these automata to those ob- 
tained for the expression -iGDltl- We present two 
tables: the first summarizes experiments on the sin- 
gle transition diagram from the previous section and 
the second summarizes experiments on the two tran- 


sition diagram. As an experiment in how the place- 
ment of temporal operators affects the construction 
of automata from LTL formulas, the first table in- 
cludes an additional column, “Distrib” , for which we 
distributed all X operations in Dltl formula over 
boolean operators before compiling to an automaton. 


/ I u I Split I Dba I via Dltl I Distrib 



In these tables, the difference between the two algo- 
rithms is striking. The direct translation still shows 
linear growth as we vary the bounds under a trivial 
assume portion. For the first section of the first table, 
the LTL-based algorithm shows exponential growth. 
The difference between zero and one transitions in the 
assume portion is not significant for either algorithm 
in the first table. Unfortunately, we were unable to 






generate the LTL-based automata for larger configu- 
rations than those shown within a reasonable amount 
of time (several hours per construction). However, 
the existing results are sufficient to demonstrate the 
drawbacks of the LTL approach to compiling timing 
diagrams into automata. 

6 Discussion 

The data in Section 5 suggest clear differences be- 
tween our two approaches for compiling timing dia- 
grams into Biichi automata. These differences could 
be due to the LTL-to-Buchi automaton translation, 
to our timing diagram to LTL translation, or to some 
property of timing diagrams that provides an inher- 
ent advantage over LTL. 

LTL-to-Buchi algorithms are not canonical, in that 
they may produce different automata for logically 
equivalent LTL formulas; the Distrib experiments in 
the previous section show this. The Daniele et al. 
algorithm produces smaller automata than other al- 
gorithms because it uses some simple syntactic op- 
timization techniques on propositional formulas [2]. 
More work should be done in this area; our timing 
diagrams research has yielded several formulas where 
simple manual transformations yielded much smaller 
automata from the Daniele et al. algorithm. Algo- 
rithms which perform optimizations across temporal 
operators are also needed, as our experiments show. 

Currently, no known metrics indicate when one 
LTL formula will yield a smaller automaton than 
another. Therefore, it is possible that a different 
translation from timing diagrams to LTL would yield 
smaller automata. For several timing diagrams, we 
have tried to manually construct LTL formulas that 
yield our Dba automata. We have been successful 
on occasion by translating the structure of Dba into 
LTL. We are still working on such a translation pro- 
cedure that acts as a fixpoint over Biichi automata, 
as a means of understanding the LTL-to-Buchi algo- 
rithms better. However, this approach is clearly re- 
dundant in practice, as it requires the construction of 
Dba- We continue to experiment with other timing 
diagram to LTL translation algorithms, particularly 
ones which enable sharing of the assume portion. 


This project is part of a larger investigation into 
whether timing diagrams offer any computational 
benefits over existing logics (including LTL) in veri- 
fication contexts [4]. We have identified several dif- 
ferences between the two notations. Full timing di- 
agrams and LTL have incomparable expressive pow- 
ers [5] (this paper uses only a subset of timing di- 
agrams). Timing diagrams enable sharing of com- 
mon subexpressions to a greater extent than LTL. 
The LTL formula in Figure 4, for example, dupli- 
cates subexpressions across its disjuncts; these ex- 
pressions correspond to entire suffixes of the timing 
diagram. LTL does not appear to provide a way to 
avoid this duplication. However, it is not yet clear 
whether these duplicated expressions contribute to 
the explosion in the generated Biichi automata. 

The most interesting distinction that we’ve discov- 
ered between timing diagrams and LTL arises from 
the structure of the Biichi automata corresponding to 
each notation. Our timing diagram to Biichi trans- 
lation always produces a particular structure of au- 
tomaton known as a weak automaton [11]. An au- 
tomaton with states Q and fair set T is weak if there 
exists a partition of Q into disjoint sets Qi,...,Q n 
such that (1) each Qi is either contained in T or is 
disjoint from it, and (2) the Qj’s are partially ordered 
so that there is no transition from Qi to Qj unless 
Qi < Qj- Weak automata have several attractive 
features in the context of verification [11]; for exam- 
ple, symbolic cycle detection is effectively linear in 
weak automata., whereas existing algorithms for the 
general case are quadratic [6]. 

Another feature of weak automata is important to 
our study of timing diagrams: complementation of 
weak automata requires only complementation of the 
fair set the structure of an automaton and its 
complement are otherwise identical. In Section 5, we 
explored translations of timing diagrams and their 
negations to Biichi automata. Our direct translation 
produces the same size automaton for a given timing 
diagram under each experiment because we exploit 
this feature of weak automata. 3 LTL-to-Biichi algo- 
rithms do not currently consider weak automata; this 
is an open problem as many LTL formulas do not cor- 

3 We require one extra transition to handle the invariant. 



respond to weak automata. When we use LTL as an 
intermediate language, the Biichi automata for the 
negated timing diagrams are much larger than in the 
non-negated case. This is partly due to the struc- 
ture of the LTL formulas corresponding to timing 
diagrams. As Figure 4 shows, LTL formulas corre- 
sponding to timing diagrams involve disjunctions of 
long sequences of conjunctions and temporal opera- 
tors. The negation of such a formula contains many 
more disjunctions than the original formula. Disjunc- 
tions force branching and extra states in Biichi au- 
tomata. It is therefore not surprising that the au- 
tomata for the negated timing diagrams are so much 
larger than those for the one-pass timing diagrams. 

In summary, many factors influence the size of the 
automata obtained when treating timing diagrams 
as an interface to LTL. These factors suggest a host 
of research problems in verification. We fully ex- 
pect that improved LTL-to-Biichi algorithms would 
reduce the sizes of automata generated in our exper- 
iments. Until researchers develop such algorithms, 
however, direct compilation of timing diagrams to 
Biichi automata appears a better approach for veri- 
fication applications. 
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Abstract 

This paper introduces the use of abstraction 
relationships for timed automata. Abstrac- 
tion relations make it possible to determine 
when one specification implements another, 
i.e. when they have the same set of com- 
putations. The approach taken here permits 
the hiding of internal events and takes into 
account the timed behavior of the specifica- 
tion. A new representation of the semantics 
of a specification is introduced. This repre- 
sentation, min-max automata is more com- 
pact than other types of finite state auto m ata 
typically used to represent real-time systems, 
and can be used to define a variety of abstrac- 
tion relationships. 

1 Introduction 

This paper describes the use of min-max au- 
tomata to specify the behavior of real-time 
systems compactly. Originally developed [2] 
as an alternative representation of timed be- 
havior for the Modechart language[12], in 
order to support the evaluation of abstrac- 
tion relationships between Modechart spec- 
ifications, min-max automata are a general 
construct for representing the behavior of 


timed systems. Min-max automata are a 
more general form of automata than the 
computation graphs originally developed for 
Modechart [27], but are more compact than 
other types of automata which represent the 
passage of each unit of time as a distinct edge. 
Thus, min-max automata are more suitable 
for model-checking and automated evalua- 
tion of abstraction relationships between au- 
tomata. 

Abstraction and refinement relationships 
permit the evaluation of whether one speci- 
fication can replace another. When can one 
specification replace another? What does it 
mean for two specifications to have the same 
behavior or for one specification to have more 
general behavior? Abstraction permits the 
substitution of module with a simpler im- 
plementation for one that is more complex. 
In abstraction, modules can be simplified by 
hiding internal details or by simplifying tim- 
ing constraints. 

There are several important uses for ab- 
straction relations. This work was primar- 
ily motivated by the desire to ameliorate the 
state-space explosion problem which arises in 
mechanical model-checking. If one specifi- 
cation is an abstraction of another (i.e. it 
has more general behavior), then all behav- 



iors of original are behaviors of the abstrac- 
tion. Therefore, it may be advantageous 
to mechanically verify the abstraction rather 
than the original specification, should it have 
a more compact representation. Frequently, 
abstractions are created in an ad hoc man- 
ner in order to perform model checking. This 
research provides a formal basis for creating 
and using abstractions for real-time specifica- 
tions. 

Two other scenarios for using abstraction 
relations merit discussion. First, abstractions 
may be applied as part of a “top-down” de- 
velopment procedure. First, a very general 
specification of a real-time system may be 
defined. Then, a series of refinements may 
add increasing detail, resulting in specifica- 
tions which are more operational. If this se- 
quence of refinements is designed while main- 
taining an abstraction relation at each step, 
then properties which have been verified at 

In particular, for real-time systems, the 
process of refinement might include the spec- 
ification of tighter and tighter timing bounds 
as assumptions about the environment of a 
system are refined, the previous step will hold 
for each refinement step. 

The last scenario involves showing an ab- 
straction relationship between two specifica- 
tions where one represents an implementation 
and the other represents the properties which 
must hold. In this case, instead of performing 
model-checking, one shows that a property, 
described as a specification, holds for the im- 
plementation. 

Because of the timed behavior of Mod- 
echart specification, it is not possible to use 
the standard notion of program equivalence 
used to relate untimed concurrent programs 
[23]. The usual approach relies on the repre- 
sentation of the system as a labeled transition 
system. The original behavior representation 


of a Modechart specification [27], a compu- 
tation graph, is a type of labeled transition 
system which captures the untimed behavior 
of a Modechart specification. Timing infor- 
mation is described in associated separation 
graphs. As a consequence it is not possible 
to define abstraction relationships directly for 
computation graphs. 

The approach taken here is to represent all 
timing constraints explicitly in the labeled 
transition system. Then, the simulation re- 
lationships described in the literature can be 
directly applied. A new type of labeled tran- 
sition system, min-max timed automata , are 
introduced. Each edge in the automata rep- 
resents either the passage of time or a dis- 
crete system event which takes no time. Min- 
max automata represent elapsed time with 
time-passage edges which specify the mini- 
mum and maximum amount of time which 
can elapse between two discrete events. 

The rest of this paper is organized as fol- 
lows: Section 2 introduces both discrete- 

timed automata and min-max automata. 
Section 3 describes the extensions to the 
usual definitions for a move in an automata 
necessary to define abstraction and simula- 
tion relationships. Section 4 defines bisim- 
ulation and trace inclusion relationships for 
min-max automata. Conclusions and future 
work are found in Section 5. 

2 Definition of Min-Max 
Automata 

This research is motivated by two goals. 
First is the ability to mechanically evaluate 
abstraction relationships between automata 
representing timed systems. Second is achiev- 
ing a compact representation of timed sys- 
tems. These goals are achieved by the use of 



min-max automata in which each time pas- 
sage edge denotes a range of possible times 
elapsed. This results in a more compact rep- 
resentation than other approaches because 
multiple paths can be collapsed into one. 

However, because each path in the min- 
max automata can potentially represent more 
than one timed execution of a system, the 
usual notions of bisimulation and abstraction 
relations cannot be directly applied. 

Definition 2.1. A min-max automata, A is 
defined as the tuple 


So, Si, S2, . . . s n , such that for all i, .<q , 

a is called a finite execution fragment of A, 
and one can write 5 0 — — >■ s n . For an infi- 
nite sequence, the notation s 0 is used. A 
move of A, indicated by 5 =>■ s', occurs if 
s — % s' and 7 = <7. Thus, a move ignores 
internal actions. 

If s 0 is an initial state of A, then <7 is an 
execution of A. The sets, execs*(A),execs w , 
and execs(A) indicate the sets of finite, infi- 
nite, and executions of A. If the time pas- 
sage actions are removed, (<7), the result- 

...... . ing sets are the untimed finite, untimed in- 

<states[A),imtial(A),actions(A),next(A)>.. . . . , ,. r . , 

' ' ' 7 finite, and untuned executions of A, de- 


where 


The initial 

states(A), 


states, initial(A) 


C 


• The actions of A, actions(A), is the 
union of the the sets external(A) and 
{r} and times(A) = {(min, max) : 
min, max 6 {Z+ Uoo} and min < max} 
where r is called the internal action and 
times(A) are time-passage actions, and 

• The next-state relation, next(A) is a 
subset of states(A)xactionsxstates(A). 

Min-max automata, like discrete timed au- 
tomata, are examples of Lynch’s [ 22 ] untimed 
automata. And like discrete-timed automata, 
the time-passage actions can be used to assign 
occurrence times to external events in a trace 
to form a computation. 

r is distinguished as the internal action of 
A. It is considered to be invisible outside of 
A. If a is a sequence of actions in actions(A), 
then <7 is the same sequence with all r actions 
removed, and a is the sequence with the time 
actions (elements of times(A)) removed. 

If (5, a, s') C next(A), then the notation 
5 s' may be used to indicate this. If there 
is a sequence, a for which there are states 


noted execsu(A), execs'^, and execsjj(A). If 
the internal action is removed from an ex- 
ecution of . 4 , 7 = <7, the resulting se- 

quence is called a trace of A. The sets of 
traces of A are traces*(A), traces w (A), and 
traces(A) for the finite, infinite, and all traces 
of A. The corresponding untimed traces, 
tracesu(A),tracesu(A), and tracesjj(A) are 
also defined, for the corresponding 7. 

The actions in the set external(A) repre- 
sent the discrete, externally visible actions of 
the system. In the context of Modechart, 
these could represent mode entry, mode exit, 
and mode transition events which are visi- 
ble on the interface of a Modechart module. 
The symbol r is used to represent internal 
events which can not be observed externally. 
Both external(A) and r events occur instan- 
taneously. The set external(A)U{T} is called 
cliscrete(A). 

The time passage actions represent the 
passage of an amount of time between the 
values of min and max. When they oc- 
cur in an execution, they represent time 
elapsing between the instantaneous exter- 
nal and r events. The values of a time- 
passage edge, e, are indicated by min(e) and 
max(e). A timed event sequence is a se- 



quence 8 = d 0 , d\, d 2 , ■ ■ . with d ,■ = (cq,A) G 
discrete(A) X Z + and increasing. If the 
timed event sequence corresponds to some ex- 
ecution <7 of A such that for every d t G b, if 
cq = cr^. then f,- > o<j<k min(crj) and 

<7jE<imes(a) 

< y] o<j<k max(<jj ) if maxj ^ oo for 

< 7 , Efiraes(a) 

all j. If maxj = oo for any j, then only the 
lower bound restriction holds, then h is called 
a timed execution of A. It can be observed 
that 8 assigns times to the discrete events in 
cr in a way that is consistent with the time 
passage events in a. If the timed event se- 
quence corresponds to a trace of A it is called 
a timed computation. comps(A) indicates the 
set of timed computations of A. 

3 Issues in Defining Ab- 
straction Relations for 
Min-Max Automata 

Direct application of the definitions for ab- 
straction relations described in the litera- 
ture is problematic, since each path through 
a min-max automata represents more than 
one (timed) computation. As a consequence, 
soundness and completeness results which 
hold for the ordinary definitions of abstrac- 
tion relationships (e.g. bisimulation) will 
hold for traces of min-max automata, but not 
necessarily for computations. 

Moreover, time-passage edges have some 
properties which cause unexpected results 
when the ordinary abstraction relations are 
applied directly using the usual definition of 
a move. The definition of a move is relaxed, 
leading to more powerful abstraction rela- 
tions. 

Example 3.1. Consider the min-max au- 
tomata P and Q, depicted in Figure 1. 


P Q 



4 O 


Figure 1: Complications in matching time 
passage edges in a min-max automata 

The ordinary definition of a move will not 
permit the sequence 0 — >p 1,1 — >p 2, to 
be matched to 0 =>■ 4 in Q, for any of the 
abstraction relations described. Yet, the two 
systems describe the same set of timed com- 
putations and have very similar structure. 

It should be possible to extend the def- 
inition of a move to permit a single time- 
passage edge to be matched with an appro- 
priate sequence of time-passage edges in the 
abstraction such that a time passage edge on 
(m,n) could be matched by a sequence of 
time passage edges whose minimums sum to 
77? and whose maximums sum to n. How- 
ever, the definitions of abstraction relation- 
ships described in the literature match a sin- 
gle edge to a move. That is, if a min-max 
automata has an edge with action (1,2) fol- 
lowed by (2, 3), while it can be said that the 
automata moves on (3, 5), what move should 
each of (1,2) and (3, 5) be matched to in the 
abstraction automata? 

Other approaches (discrete-timed 
automata[3] and [22] for example) ad- 



dress this problem by hlling in all the 
possible time passage edges. In this case, 
if there were an edge (3, 5) in a min-max 
automata between points s and s ' , then there 
would have to be every possible sequence of 
edges between s and s' such that the sum of 
the minimum times was 3 and the sum of 
the maximum times was 5. However, this 
defeats the purpose of min-max automata 
which is to provide a finite and more compact 
representation of a system, by using min-max 
time passage edges. 

Instead, the problem is addressed by defin- 
ing a canonical representation for a sys- 
tem. The canonical representation combines 
all sequences of time-passage edges and re- 
places them with new edges corresponding 
to a move. In the example, the sequence 
(1,2), (2, 3) would be replaced by a single 
time-passage edge (3,5). The abstraction re- 
lations are then defined on the canonical rep- 
resentation. A canonical representation of a 
min-max automata, A, denoted can(A), is de- 
fined by computing the closure of a min-max 
automata with regard to the time-passage 
edges and deleting all but the maximal length 
edges. 

A consequence of computing the canoni- 
cal representation of a min-max automata is 
that some points are left unreachable. Since 
the canonical representation represents the 
same set of timed computations as the orig- 
inal min-max automata, this is of no conse- 
quence. However, the definitions of the simu- 
lation relationships must be adjusted to take 
this into account. The unreachable points are 
not required to be included in the simulation 
relations. 

Definition 3.1. A point s in a min-max au- 
tomata is reachable if there is a sequence a 
such that So — — >■ •§, where s 0 is an initial point 
of the automata. The set of reachable points 


of an automata A is denoted reachable(A). 

The abstraction relations will be defined al- 
most identically as in the literature. However, 
only reachable points will be included and the 
canonical representation of the min-max au- 
tomata will be used. This will address the 
anomaly from Example 3.1. 

A second issue is described in Example 3.2. 
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Figure 2: Rationale for a relaxed-time move 
in a min-max automata 


Example 3.2. Consider min-max automata 
P and Q, depicted in Figure 2. 

Then comps(P) C comps(Q), but there is 
no abstraction relationship between P and 
Q. If the individual computations were rep- 
resented on separate paths as they are for 
discrete-timed automata, then an abstraction 
relation would exist. 


This problem is avoided by extending the 
dehnition of a move, to permit time-passage 
edges to be matched to time-passage edges 
which are inclusive of the times represented 
by the original edge. That is, a time-passage 
edge (m, n) will be matched to a time-passage 
edge (ra', n') if m' < m and n < n' . 

First, a time-relaxed step , relaxes the tim- 
ing requirements of a time-passage edge. 


Definition 3.2. If s s > ^ an( ] m ' < m 

and n < n', then s ^ i-V ^ s' 



Next, the definition of a move is expanded 
to accommodate time-relaxed steps. 

Definition 3.3. A time-relaxed move of A, 
indicated by s 0 .s„, occurs if 7 = <7 where 
a is a sequence of states, s 0 , Si, s 2 , • • • s m such 
that for all i, s, or A- s; + i- 

By substituting time-relaxed moves for or- 
dinary moves in the definitions of the abstrac- 
tion relations, the anomaly described in Ex- 
ample 3.2 is avoided. It is now possible to 
define abstraction relations for min-max au- 
tomata. 

4 Abstraction Relations 
for Min-Max Automata 

This paper now considers the issues of when 
one specification is an abstraction (or imple- 
ments) another specification. Trace inclusion 
or trace equivalence has been widely used 
to describe when one system implements an- 
other [21, 22], The terms simulation [21], 
homomorphism [18], and refinement mapping 
[ 1 ] have all been used to reduce the problem 
of showing trace inclusion to proving some- 
thing about transitions in some kind of au- 
tomata. Thus, only a local property needs to 
be demonstrated. All of these techniques re- 
late systems in terms of the timed behavior 
of visible events. In each case, the behavior 
of internal events is hidden. This section de- 
scribes several such relationships in the con- 
text of discrete-timed automata. 

4.1 Bisimulation and Forward 
Simulation 


is called bisimulation [25]. Bisimulation in- 
volves finding a relation on the states of two 
systems such that two states being bisimi- 
lar means that each state has an edge to a 
state so that the resulting states are bisim- 
ilar. This approach can be relaxed (called 
weak bisimulation) so that an edge in each 
system is matched by a move (including in- 
ternal events) so that the resulting states are 
bisimilar. Bisimulation is a rather conser- 
vative notion of system equivalence, as it is 
sound but not complete, but it is widely used 
especially in process algebras [24]. 

In order to hide internal events, a sequence 
of steps, or a move is more relevant to the 
question of whether two automata similarly. 
A move, as defined above, is a subpath be- 
tween two points where no intervening events 
are externally visible. A weak bisimulation 
[25] relaxes the requirement that the two sys- 
tems proceed in lockstep. Rather, it is only 
necessary that an edge between two points 
correspond to a move between two points. 

Definition 4.1. For min-max automata, 

P and Qi r C reachable(can(P))x 
reachable{can(Q)), is a weak bisimula- 
tion, if 

• for all p E initial(P), there is some q, 
such that (p,q) E r and q E initial(Q), 

• for all q E initial(Q), there is some p , 
such that (p,q) E r and p E initial(P), 

• if V(p, g)Er: 

— if p — p' then 3 q' : q q' and 
(//, q') E r, and 

— if q — q' then 3 p' : p p' and 
(]/, q') E r. 


One common technique for showing that Informally, this states that two points are 
two systems are observationally equivalent bisimilar if any edge from one of the points 



can be matched by the other point making a 
move on the same event and reaching a point 
that is weakly bisimilar to the point reached 
from the first point. Since weak bisimulations 
are closed under union, it can be shown that 
there is a largest weak bisimulation, denoted 
~, for any pair of computation graphs for a 
given set of observable events. 

The following theorem establishes the 
soundness of bisimulation. 

Definition 4.2. The notation comps(P) = 
comps(Q) indicates comps(P) C comps(Q) 
and comps (Q) C comps(P). 

Theorem 4.1. P « Q => comps(P) = 
comps(Q). 

Proof. Similar to the proof for ordinary timed 
automata found in the literature [22]. The 
proof is in [2], which shows that the exten- 
sions to the definition of a move do not violate 
the conditions of the usual proof. □ 

Bisimulation is not complete. That is, 
there are systems which have the same set 
of timed traces, but which are not bisimilar. 
This is because bisimulation captures some 
aspects of system structure. Each point must 
be bisimilar to a point in the other system 
which permits actions which move to points 
which are bisimilar to those which can oc- 
cur in the original specification. As a con- 
sequence, bisimulation distinguishes with re- 
gard to the state of the system as well as the 
sequence of actions or events. 

4.2 Forward Simulations 

If the definition of bisimulation is modified to 
apply in only one direction, the result is called 
a forward simulation [21], Forward simula- 
tions are also related to simulations [28, 13], 
history measures [17], downward simulations 


[9, 11, 15], and possibilities mappings [20]. 
Because the restriction is in one direction, 
a forward simulation shows trace inclusion 
rather than trace equivalence. 

In practice, this approach is desirable. Of- 
ten a general purpose specification will be de- 
signed as well as an implementation or oper- 
ational specification which has a narrower set 
of behaviors. It is not necessary for the im- 
plementation to have the full set of behaviors 
as the specifications. Alternatively, perhaps a 
simplification can be made to a specification 
which reduces the size of the computation 
graph, but which admits a larger set of be- 
haviors. If the a trace inclusion relationship 
holds between the two systems, then it may 
be possible to model-check the simpler system 
and apply the results to the more complicated 
system. 

Definition 4.3. For min-max automata, 
forward simulation from P to Q is a 
relation / over reachable(can(P )) and 
reachable(can(Q)) a forward simulation if: 

• for all p E initial(P ), there is some q , 
such that (p,q) E / and q E initial (Q ), 

• if V(p, q) E / and all e E actions(P), 
p — p' then 3 q' : q q' and (p\ q') E 
/• 

Lynch [21] shows that forward simula- 
tions are a pre-order (i.e. they are reflexive 
and transitive). Soundness follows from the 
soundness of bisimulations. 

4 . 3 Forward- B ack war d S imula- 

tions 

Forward-Backward simulations were also de- 
scribed by Lynch and are similar to the in- 
variants and ND-measures of [16, 17] as well 



as subset simulations [14], and simple failure 
simulations [7]. They are less restrictive than 
forward simulations. Perhaps, most notewor- 
thy is that they are complete for trace inclu- 
sion. However, since a single trace of a min- 
max automata can represent more than one 
timed computation, forward-backward simu- 
lations are not complete for timed computa- 
tions. 

Definition 4.4. For min-max automata, 
forward-backward simulation from P to Q 
is a relation fb over reachable(can(A)) and 
N (reachable(can(B))) 1 such that: 

• for all p E initial(P), there is some 
set A , such that (p, A) E fb and A C 
initial(Q), 

• if p \ o' and (p, A) E fb, then there 

exists a set A' such that (//, A') E fb 
such that for every of E A! there is some 
q E A such that q ^ of . 


P Q 



Figure 3: Completeness Problem for Min- 

Max Automata 

Example 4.1. To understand why forward- 
backward simulations are not complete for 
min-max automata, consider min-max au- 
tomata, P and Q , depicted in Figure 3. 

1 For a set X, N(A') indicates the set of non-empty 
subsets of X. 


Then, comps(P) = comps(Q) but it is not 
the case that P <fb Qi because there is no 
match for the time-passage edge, (3, 5). 

Therefore, further research is required to 
find an abstraction relation which is complete 
for computations of min-max automata. 

4.4 Homomorphisms and Re- 
finements 

Homomorphisms [8, 18] and refinement map- 
pings [1, 19, 21], are more restrictive than 
forward simulations, because they require a 
function from states(P) to states(Q) rather 
than a relation. 

Definition 4.5. For min-max au- 
tomata, P and Q , a function / between 
reachable (can(P)) and reachable(can(Q )), 
is a refinement if: 

• for all p E initial(P ), f(p) E initial(Q), 

• if for all e E actions(P) p p' then 

f(p) ^ f(p') 

The proof of soundness for forward simula- 
tions, forward-backward simulations, and re- 
finements is similar to that for bisimulations. 

Another interesting type of relationship be- 
tween two automata is failures inclusion or 
equivalence, developed by Hoare [4, 10]. An 
alternative characterization, given by Hen- 
nessy and de Nicola [6], is called testing 
equivalence in which equivalent automata 
pass or fail the same set of tests. Testing and 
failures relationships cannot be characterized 
by matching an edge in one automata with 
some kind of move in another automata and 
so are not discussed in this paper. 



5 Conclusions and Future 
Work 

This paper has introduced min-max au- 
tomata which are a compact form of timed 
automata suitable for mechanical evaluation 
of simulation and abstraction relationships. 
Extensions to the definition of a move nec- 
essary to support simulation and abstraction 
relationships were defined and several types 
of equivalence and abstraction/simulation re- 
lationships were described in the context of 
min-max automata. Related research efforts 
extend these ideas by describing automatic 
generation of abstractions [2]. 

Future work involves integration of min- 
max automata into existing software tools 
to automatically generate min-max automata 
for Modechart specifications and to automat- 
ically check for the simulation and abstrac- 
tion relationships defined in this paper. The 
Modechart Toolset [5, 26] provides a graphi- 
cal interface for editing, consistency-checking, 
simulation, and verification of real-time spec- 
ifications in the Modechart Language. This 
will permit evaluation of the techniques on 
real-world examples. Future work is also re- 
quired to define an abstraction relationship 
which is complete for trace inclusion of min- 
max automata. 
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Abstract 

A design formalization based on behavior tables was 
presented at Lfm97. This paper describes ongoing 
work on a supporting tool, now in development. The 
goal is to make design derivation, the interactive con- 
struction of correct implementations, more natural 
and visually palatable while preserving the benefits 
of formal manipulation. We review the syntax and 
semantics of behavior tables, introducing some new 
syntactic elements. We present a core algebra for ar- 
chitectural refinement , including new notational con- 
ventions for expressing such rules. 

Keywords: behavior table, design derivation, for- 
mal synthesis. 

1. Introduction 

Behavior table notation emerged out of case studies 
in formal design derivation between 1985 and 1995. 
The DDD transformation system [7] is based on func- 
tional algebra. Behavioral expressions at the level 
of algorithmic state machines [1] are represented by 
recursive systems of function definitions, and archi- 
tecture oriented implementations are represented by 
recursive systems of stream expressions. In DDD, 
these representations are manipulated as transforma- 
tions on Scheme programs, so the expressions are also 
executable. 

The primary goal in our early case studies was to 
interactively impose hardware architectures on algo- 
rithmic specifications. As these studies became larg- 

*This research is supported, in part, by the National Science 
Foundation under Grant MIP 96 10358. 


er, a practice emerged of printing DDD expressions 
in a tabular form, reminiscent of register transfer ta- 
bles. The tables helped design teams visualize their 
architectural goals so they could strategize about how 
to accomplish them in the DDD algebra. 

We began to contemplate using the tables more di- 
rectly as formal objects, retargetting the DDD alge- 
bra to operate on tabular representations. We believe 
the tables are more perspicuous to practicing profes- 
sionals who, it has been claimed, are put off by the 
notation used in formal reasoning systems. 

The rising visibility of tabular specification lan- 
guages such as Tablewise [3], SCR* [2], and and- or 
transitions in RSML [8] , helped convince us to look at 
behavior tables more seriously as a formalism rather 
than merely as a visual aid. Subsequently, we have 
undertaken to develop a tool for interactive design 
derivation using them. 

In this paper, we develop a core algebra for archi- 
tectural manipulation. In the main, this algebra cor- 
relates to the “structural” algebra of sequential sys- 
tems, presented in [5] . Although the main purpose is 
to lay the groundwork for tool implementation, one 
ancillary contribution of this paper is its notational 
conventions for stating the rules of the algebra, which 
use table schemes to simplify quantification. 

The conclusion lists additional topics and issues 
entailed in the implementation effort. We extend the 
term-level syntax presented at Lfm97 [6] to include 
provisions for bounded indirection, additional algebra 
for a simple kind of data refinement, and possible 
extensions for verification. 



2. Terms 

Behavior tables are arrays of terms in a ground vo- 
cabulary of constants and operations. We very briefly 
review the terminology of first order structures then 
introduce the extensions that are assumed in behav- 
ior tables. 

A first order structure describes a family of value 
sets, Ai, . . . , A n , together with a collection of to- 
tal functions, /i, . . . , f m , on these sets. With each 
set Ai is associated a type symbol, Tj,. There are 
constant and operator symbols representing the func- 
tions fi, and a distinct set of variable symbols. The 
notation v: Ti asserts that the variable v ranges over 
values in A, . The signature of an operator specifies 
its domain and range, which in general are nested 
products. The formula /: (n, (r 2 , 73)) -4 (t4,t 5 ,t 6 ) 
asserts that the operation / maps the product Ai x 
(A 2 X A 3 ) to the product A 4 x As x Aq. We shall 
allow for multioutput operations, as suggested here, 
whose output signatures are n- tuples. 

A term is a variable, constant, or application, 
/(Ti, . . . , T n ), of an operation / to the terms T) ac- 
cording to the f's signature. 

A structure becomes an equational algebra when 
it is provided with a set E of equational identities 
among terms (over a distinguished set of logical vari- 
ables). E induces an equivalence relation; and we 
write 1 =e s = t to express the fact that s and t are 
provably equivalent under E. 

Certain additional features are assumed of al- 
1 structures used in behavior tables and are thus ab- 
sorbed at the metalinguistic level. 

• A sort Bool is assumed with constants true and 
false and the identities of boolean algebra. Oper- 
ations with range Bool are called tests. 

• A don’t care constant is designated by ‘t|’. 

• Finite product (tupling) and projection opera- 
tions of each type are assumed Projections are 
denoted by sans-serif adjectives, 1st, 2nd, 3rd, 
4th, 5th . . ., ith, . . .. An n- tuple is expressed as 
a parenthesized series of n terms, (Tj, . . . , T„). 
Projections applied to n-tuples can be simplified 


at the syntactic level; for instance, 

h2nd(T 1 ,T 2 ,T 2 ) =T 2 

• It is assumed that arbitrary finite sets of tokens 
can be represented (e.g. by n-tuples over Bool). 
We shall extend this idea to what Hoover calls a 
finite logic [ 3 ] , with which we associate a specific 
selection operation, written 

case s of 
ai : ti 

a fc : h 

The usual treatment of terms is extended for ex- 
plicit multioutput operations. The definition of sub- 
stitution on terms is adapted for multioutput opera- 
tions by allowing nested lists of variables to serve as 
substitution patterns. Such a list is called an identi- 
fier. 

Definition 1 An identifier is either a variable or 
a nested list, (Xi, . . . ,X n ), of distinct identifiers, 
meaning that they share no common variables. 

Definition 2 The formula T[R/X] denotes a sub- 
stitution of the term R for the identifier X in the 
term T. The formula T[Ri/X \, . . . , R n /X n ] denotes 
the simultaneous and respective substitutions of terms 
Ri for identifiers X{, i £ (1 . . 71} . Substitution is de- 
fined by induction on the language of terms. In the 
base cases, constants are unchanged and for a vari- 
able symbol u, 

r r> / f R if ^ ^ 

u[R/X\=< 

L J [ u if X u 

For applications and n-tuples, 

/(7j,...,T n ) [R/X\ = /(Tr [R/X] ,...,T n [R/X \ ) 

For nested identifiers, a simultaneous substitution 
is done on the constituents: 

T[R/{X 1 , ...,X n )}= Tlls^/X!, ..., nth{R)/X n ] 

In the last case, substitution of an n- tuple for an 71- 
element identifier simplifies to 

T[(R 1 ,...,R n )/(X 1 ,...,X n )\ 

= T[R 1 /X 1 ,...,R n /X n ] 



3. Syntax of behavior tables 

Behavior tables are closed expressions whose terms 
contain variables from three disjoint sets: / (inputs), 
S (sequential signals, or data state), and C (combi- 
national signals). Fix these sets for the remainder of 
this section. We will write ISC for / U S U C and 
SC for SUC. We use the term “register” for an el- 
ement of S, but this is a euphemism that should be 
interpreted very abstractly. There is no assumption 
that these variables denote finite values, nor are ta- 
bles intended only for register-transfer specification. 
The form of a behavior table is: 


Name: Inputs -A Outputs 

Conditions 

Registers and Signals 



Guard 

Computation Step 




Inputs is a list of input variables and Outputs is a 
set of terms over ISC, but without loss of generality, 
assume O C SC. Conditions is a set P of predicates 
over ISC, that is, finitely typed terms ranging over 
finite types, such as truth values, token sets, etc. 

The notion of term evaluation used here is stan- 
dard. The value of a term, t, is written cr[f], where a 
is an assignment or association of values to variables. 

Definition 3 A guard is a set of constants indexed 
by a condition set P: g = {cp} pk p . A decision table 
D = [P, G ] , consists of a condition set and a an as- 
sociated list of guards. We say g holds for an assign- 
ment a to ISC when, for each p G P, either c p = t] 
or <r[p] = c p . 

Following [3], we say a decision table is functional 
when G describes a proper partitioning of the possible 
assignments to ISC. In other words, the guards are 
“consistent” and “complete”. 

Definition 4 A computation step or action is a 
set of terms, one for each register and signal: a = 
{/ , },gsc • An action table is a set of actions typical- 
ly indexed by the guards of a corresponding decision 
table. 



| MULT: (go, a, b) — > (done*, w) 
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w 
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a 

b 

0 

P A -igo 
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1 
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ti 
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0 
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0 

0 

0 
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vX 2 

w+v 

P A ->go 


where P = (zero? u) V (zero? v) 


Figure 1: Example of a behavior table 

Definition 5 A behavior table for / — > O consists 
of a decision table, D, with guards G = {(ji, ... g n }, 
and an action table indexed by G, A = {t v k \ v G 
SC and g k G G}. 

Figure 1 shows a shift-and-add multiplier, ex- 
pressed as a behavior table. The timing diagram is 
provided to explain the interface, with multiplication 
performed within a full handshake. 

4. Synchronous semantics 

A behavior table [D, A] for O C SC denotes a rela- 
tion between infinite input and output sequences. We 
call these sequences streams because in prior work 
we obtain a semantics by interpreting a table as a 
(co)recursive system of stream-defining equations [7], 
More directly, suppose we are given a set of initial val- 
ues for the registers, {ijsfs and a stream for each 
input variable in I. Construct a sequence of assign- 
ments, (<7o, <7i . . .) for ISC as follows: 

(a) a n (i ) is given for all i G I and all n. 

(b) For each s G S, oo (s) = x s . 

(c) cr„_|_i(s) = cr„[i s>fe ] if guard g k holds for a n . 





(d) For each c € C, a n (c) = <7„[i c , fc ] if guard g k 
holds for < 7 n . 

The stream associated with each o £ O is 
(<To(o), (Ti(o), . . .). This semantic relation is well de- 
fined if there are no circular dependencies among the 
combinational actions {t r k \ c £ C, g k £ G}. The 
relation is a function (i.e. deterministic) if decision 
table D is functional. We shall restrict our attention 
to behavior tables that are well formed in these re- 
spects. In essence, well formedness reflects the usual 
properties required of synchronous finite state ma- 
chines. 

To achieve well formedness, we constrain behavior 
tables in two ways. First, we prohibit “combinational 
feedback” in the actions. Given row k in the action 
table {t Vi k | v £ SC}, there is a natural dependence 
graph with vertices corresponding to the signal names 
and edges given by the relation: a b iff a is a 
subterm of t b,k- Checking for combinational cycles is 
a straightforward depth-first search. 

Even if the actions themselves do not contain com- 
binational loops, the decision table can still induce 
race conditions or metastable behavior. Consider the 
following table fragment where r and c are registered 
and combinational boolean signals: 


B-. I O 

r 

c* 


r 

c* 


0 

0 


0 

1 


0 

1 


0 

0 


1 

0 


1 

1 


1 

1 


1 

1 



Intuitively, if the system makes a transition into a 
state where a n (r) = 0, then combinational signal a 
will oscillate. Our semantics is not well defined in this 
case: if c r = 0 and c c = 0 in some guard g k = {c p } p g p 
at timeslice n, then a rl (c) = 1 by (d). Since g k no 
longer holds at a n , some other guard gj = {dp}peP 
in which d r = 0 and d c = 1 hold changes <7„(c) back 
to 0. 

The race condition occurs in our example when 
(T„(r) = 1 and <t„(c) = 0. Although one could argue 
that a n is well defined, we shall prohibit this mode of 
expression anyway, as it reflects a kind of transition 


To eliminate these scenarios, we constrain the pred- 
icates of the decision table to use only registered vari- 
ables and input signals. This way, no action can di- 
rectly change the guard g k since the values of regis- 
tered signals persist for the duration of the present 
action (c). 

In addition, we shall require a functional set of 
guards, as noted earlier. This results in deterministic 
and total behavior, for which the algebra presented 
here is intended. 

We think of behavior tables as denoting persisten- 
t, communicating processes, rather than subproce- 
dures. In other words, behavior tables cannot them- 
selves be entries in other behavior tables, but instead 
are composed by interconnecting their I/O ports. 
Composition is specified by giving a connection map 
that is faithful to each component’s arity. In our 
function-oriented modeling methodology, such com- 
positions are expressed as recursive systems of equa- 
tions, 

X(Ui,. .. ,U n ).(Vi, ... ,V m ) where 

(X lu ...,X lqi ) = Ti(W lu ...,W Ul ) 

(Api , . . . , Xpq p ) = Tp{Wpi , . . . , Wp £ p ) 

in which the defined variables Xij are all distinct, 
each 7fe is the name of a behavior table or other com- 
position, and the outputs V k and internal connec- 
tions Wij are all simple variables coming from the 
set {Ui} U {X jk }. 

Valid systems must preserve I/O directionality, ex- 
cluding both combinational cycles and output con- 
flicts. Checking validity has two stages and is again 
a graph problem: 

1 . For each behavior table let its inputs and outputs 
be vertices, and let i — ¥ o when output signal o 
combinationally depends on input signal i. 

2. Add the following edges to the disjoint union 

of the behavior table I/O graphs: o — > j 

when Tj (. . . ,o, . . .) is the right hand side of 
an equation where 7/’s I/O signature is Tj '■ 

— > O. 


race. 




A legitimate connection network exists when this 
graph has no cycles. 

Provided they are well formed, deterministic sys- 
tems are readily animated in modeling languages that 
allow recursive stream networks to be expressed [4]. 
As long as each register has an initial value, the 
streams are constructed head-first as a fixed-point 
computation. Translation to both cycle-based and 
event-based simulation languages is also relatively s- 
traightforward, as long as the systems are expressed 
over the concrete data types these tools recognize. 

A synchronous semantics is simple and suited to 
the clocked implementation models most high-level 
synthesizers use. In fact, behavior tables will acquire 
a range of semantics, depending on their applications, 
just as HDLs and programming languages do. Even 
with a variety of interpretations, their inherent struc- 
ture helps reduce the mathematical bookkeeping that 
often obscures semantic definitions. 


5. Behavior Table Algebra 

The collection of transformation rules presented in 
this section applies to architectural refinement. This 
set is not claimed to be complete nor is minimal in 
any mathematical sense. At this stage, our principal 
object is to build a set of rules that is robust enough 
to serve as a core rule set for tool implementation, 
mathematical efficiency is a secondary concern, for 
the moment. 


5.1. Notational conventions 

Defining these rules has led to some stimulating no- 
tational issues. In attempting to present the rules in 
a clear way, we have been led to consider some novel 
conventions for expressing features, particularly for 
quantification. For reasons of both typography and 
clarity, we want to reduce use of ellipses, columns, 


and subscripts to describe a table as, for example, 



Our table scheme notation uses the table itself as a 
quantifier, and uses set elements as indexes rather 
than number ranges. Uppercase italic variables de- 
note sets; and differently named sets are always as- 
sumed to be finite and disjoint. Lowercase italic vari- 
ables denote indices ranging over sets of the same 
name. The form 



represents a two-dimensional array (table) of items, 
{a;,... | r E R and s E 5 1 }. A san seriff 1 identifier 
denotes a fixed (throughout the scope of the rule) 
element from the set of the same name. Thus, the 
form 


s 



represents a column, {x rs | r E /s'} , and similarly for 
rows. 

Under these conventions, the table scheme from 
Section 3 looks like 



The use of ellipses 1 • • • N on the left is not necessary, 
but serves as an reminder that the rows are typically 
numbered. That is, we usually take the set N to be 
the first “IV” numbers. 

5.2. The rules 

Some structural rules subsumed by the semantics, 
must be implemented in the tool. For example, inter- 
changing rows and columns is allowed since indices 

1 Where possible, we display these identifiers in red- 





range over sets, not sequences. The underlying se- 
mantics remain well defined because the order of e- 
quations in a system is irrelevant. Similarly, renam- 
ing variables is allowed under the usual rules of a 
substitution 2 . 

The rules fall into three groups, the first involving 
both the decision and action table parts, the second 
being operations on the action table part, and the 
third being operations that affect the decision table 
part. 


Replacement 
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One term can be replaced by another term that is 
(proven to be) equivalent in the underlying structure 
(or theory). Recall that |= t = u is a provable e- 
quivalence in the underlying structure. In practice, 
establishing equivalence would be done with a rewrit- 
ing tool or proof assistant. 


2 Actually, behavior tables do not have free variables, so « 
conversion is even simpler. 


Decomposition 
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Decomposition splits one table into two, both in- 
heriting the same decision table. The compose oper- 
ator connects the two tables to maintain the original 
dependence among the signals. Interpreting the ta- 
bles as functions on streams — and reading ‘U and T) 
as list operations — B\ o £> 2 yields the system 


B(I)=0 where 

(O n S) = B 1 (I U T) 

(onr) = b 2 (i u s) 


It is a background job of the table editor to maintain 
the connection hierarchy as a byproduct of decompo- 
sition. An upward composition transformation (f| ), if 
formulated, would require conditions to exclude name 
clashes and preserve well formedness. In using tables 
for design derivation, one would typically decompose 
tables rather than compose them. 

This is by no means all there is to say about com- 
position. This strong (in the sense of not being very 
general) form of the Decomposition rule is essentially 
a partitioning rule, allowing one to to impose hierar- 
chy on designs. 



Conversion 


instantiation. 
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case q { V, q ; f js } ; 





Compatible means that both variables must be com- 
binational or both must be sequential. If both sig- 
nals are combinational, an audit is required to assure 
that the resulting system remains well formed, that 
is, that instantiation does not introduce feedback. 


This rule, allowing function to be moved between Action identification 
the decision and action parts of a table, provides the 
means to change the boundary between control and 
architecture. The side conditions say that, within the 
range indicated by J, the guards outside column q a- 
gree, and the guards within column q are exhaustive. 

Action collation 
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The idea behind collation is that two, or several, com- 
patible signals can be merged into one by instantiat- 
ing don’t-cares. The ‘o’ operator denotes term-level 


In terms of systems, this is the recursion rule, stat- 
ing that y is equal, in a logical sense, to its defining 
equation, and hence that one can be replaced for the 
other. In fact, this rule can be applied on a row- 
by-row basis, but we give the full-column version to 
reflect the more typical case when a common subter- 
m is being identified. If y were a sequential variable, 
it would acquire the value r ny in the next step and 
so the replacement is invalid. 



Action introduction 
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A new action column can be added (JJ-) as long as 
the signal name is not redundant and, in the case of 
combinational signals, the action terms do not refer 
to the signal being introduced. 

Action grouping 
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( both comb, or both seq.) 


Action table entries need not be explicit tuples, al- 
though they can be, because 1, 2, etc. are legitimate 
operators. 

Decision grouping 
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As with action tables, decision table columns can be 
grouped into tuples. In contrast, the entries are val- 
ues and the headers are terms, so explicit use of de- 
tupling projectors is allowed in both. 

Decision introduction 
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Columns can be grouped and ungrouped as long as 
the resulting columns are purely sequential or pure- 
ly combinational. Thus, one canonical form for ac- 
tion tables has just two columns. Recall that signal- 
s names are nested identifiers; the notation l "l(s)"’ 
means that ungrouping transformations require ex- 
plicit tuples in the header fields, and destructure 
them in the obvious way. For instance, if s = (a, b) 
the ungrouped columns will be headed with a and b. 
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One can introduce a new test with don’t-care criteria. 
The underlying intent of this rule is its use in ad 
hoc table constructions. A possible well formedness 
restriction on this rule is that the resulting table be 
safe from race conditions. Such a restriction can, in 
principle, be applied when decisions are instantiated 
(see just below), yielding a more general algebra. 



Decision instantiation 
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Having introduced a new test to a behavior table, 
instantiation is used to do case splitting. In the sim- 
plest case, suppose that a 1] appears in a decision table 
entry. Then this rule provides for expanding that row 
into enough duplicates to account for all the possible 
values of the test. In the upward direction, the rule 
gives us a way to combine rows whose actions are i- 
dentitical. The notation / q U </ q anticipates allowing 
for decision table entries to be sets of values, as is 
seen in requirements specification languages. 

I/O restriction 

Input and output signals may be added to behavior 
tables without concern so long as the inputs and out- 
puts of the encapsulating system remain the same. 
Such additions cannot introduce combinational feed- 
back until they are used, and the decision/action in- 
troduction rules check for well formedness. 

Conversely, an unused I/O signal qualifies for re- 
moval. We can remove input * to a behavior table if 
no action or predicate contains i as a subterm. A be- 
havior table output may be removed when is unused 
in the surrounding interconnect expression. 


practice, the product of such manipulation is a de- 
composition of the specification into subsystems for 
synthesis into hardware or compilation into embed- 
ded software components. This section briefly de- 
scribes a number of other immediate issues and as- 
pects entailed in the development of a design tool. 

Figure 2 shows a derivation decomposing a be- 
havior table into two components, one allocating t- 
wo arithmetic operations to a single device. This 
is an example of a system factorization, a funda- 
mental transformation in the DDD algebra [5], and 
the instance in the figure comes from an illustration 
in Johnson’s Lfm97 presentation of behavior tables. 
The example shows that the algebraic rules present- 
ed in this paper are much more finely grained than 
the transformations that typically would be used in 
an interactive setting, but would instead serve as a 
core set of rules from which larger-scale ones are com- 
posed. 


6.1. Stream semantics 

Given a behavior table, one can construct an equiva- 
lent sequential system by repeated applications of the 
Decomposition and Conversion rules. Use Decompo- 
sition to separate every column of the action table, 
then Conversion to reduce each of the resulting tables 
to a single row. The resulting nested system descrip- 
tion can be flattened and simplified. Alternatively, 
Decomposition can be generalized to simultaneous- 
ly split tables into several components. To complete 
the transformation, we must make initialization of 
the sequential signals explicit. The resulting system 
is 


B(I) = 0 where 

| X s = x s ! select(fests, alternatives) 
1 b c = select [tests, alternatives) 


6. Other aspects 

This paper has developed a core algebra of behavior 
table manipulation for architectural refinement. In 


where the expression v ! S denotes an initialized 
stream [5], In DDD, this construction is reversed. An 
initial behavior table is built from a system of stream 
equations, each with a common selection combination 

[ 7 ]- 



6.2. Bounded indirection 

We have found an extension to the term-level syn- 
tax called indirection [11] which is highly useful for 
hardware applications and appears to be equally use- 
ful in incremental specification development. If v is a 
signal name, the term v v stands for a “reference” to 
signal v; concretely, it is actually a token which can 
later be used to select v. The term A w denotes that 
selection. As an illustration, consider the table: 



In essence, the term A s in the third row stands for 
the term: 

case s 

v t: : t 

v u: : u 

Uses of indirection include the description of bidi- 
rectional buses, other forms of implied selection, and 
control branching. Of course, such use also neces- 
sitates consistency audits over the whole table; for 
instance, to verify that selected signals are compati- 
ble and uniformly typed. 

6.3. Data refinement 

Another important set of rules for data refinemen- 
t, will be presented in a future paper. Data refine- 
ment involves the translation between levels of da- 
ta abstraction. In our approach, the foundation for 
data refinement lies in algebraic specification and e- 
quational logic. Consequently, the initial connection 
to the architectural rules presented here will lie in a 
more general version of the Replacement rule. 

However, replacement is only adequate for the s- 
traightforward, combinational expansion of simple 
representations; it does not address implementations 
that involve sequential behavior. Our research on se- 
quential decomposition, [10] has not yet been reflected 
in behavior tables. 


6.4. Verification 

We are also interested in integrating the derivation- 
al formalism with property verification. One way to 
approach this is to augment behavior tables with as- 
sertions in a suitable temporal logic. Since we are 
primarily interested in higher levels of specification, 
“model checking” [12] these assertions would likely 
require interaction. Considered as an algorithmic s- 
tate machine, the table would provide contextual in- 
formation making the proof process more agreeable. 

6.5. Animation 

Finally, animation, particularly symbolic execution, 
would be an important feature of any practical be- 
havior table tool. Consequently, we want to inte- 
grate our tool with proof assistants — particularly ter- 
m rewriters — not only to support replacement rules, 
verification and type inference, but to provide in- 
teractive simplification of terms in the fashion of 
Moore’s symbolic spread sheets [9]. 
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Figure 2: A factorization from [6] 
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Abstract 

Hybrid systems are characterized by the hybrid 
evolution of their state: A part of the state changes 
discretely, the other part changes continuously over 
time. Typically, modern control applications be- 
long to this class of systems, where a digital con- 
troller interacts with a physical environment. In 
this article we illustrate how a combination of the 
formal method VDM and the computer algebra sys- 
tem Mathematica can be used to model and simu- 
late both aspects: the control logic and the physics 
involved. A new Mathematica package emulating 
VDM-SL has been developed that allows the in- 
tegration of differential equation systems into for- 
mal specifications. The SAFER example from [11] 
serves to demonstrate the new simulation capabili- 
ties Mathematica adds: After the thruster selection 
process, the astronaut’s actual position and veloc- 
ity is calculated by numerically solving Euler’s and 
Newton’s equations for rotation and translation. 
Furthermore, interactive validation is supported by 
a graphical user interface and data animation. 

1 Introduction 

Modern control applications are realized through 
microcontrollers executing rather complex control 
logics. This complexity is increased by the fact that 
control software interacts with a physical environ- 
ment through actors and sensors. Such systems are 
called hybrid systems due to the hybrid evolution of 
their state: One part of the state (variables) changes 
discretely, the other part changes continuously over 
time. 

Hybrid systems are excellent examples for moti- 
vating the use of formal software development meth- 
ods. First, their complexity calls for a real soft- 
ware engineering discipline applying both, a pro- 


cess model as well as a mathematical method. Sec- 
ond, these kinds of systems are often safety-critical 
which justifies formal validation and verification 
techniques. Third, engineers in the control domain 
are educated in the use of mathematical models for 
designing dynamic systems. 1 In our experience, the 
offer of a formal method for software development 
is more often appreciated by control engineers, than 
by software developers used to produce short cycle 
products in ’Internet time’. 

In [11] the hybrid system SAFER has been cho- 
sen by NASA in order to introduce to formal spec- 
ification and verification techniques. SAFER is 
an acronym for “Simplified Aid For EVA (Ex- 
travehicular Activity) Rescue”. It is a small, 
lightweight propulsive backpack system designed to 
provide self-rescue capabilities to a NASA space 
crewmember separated during an EVA. In this 
NASA guidebook[ll], SAFER is specified formally 
in the PVS notation and properties are formally 
proved using the PVS theorem prover [12]. In the 
guidebook the dynamic aspects are used to com- 
pare the continuous domain model from spacecraft 
attitude control with the discrete PVS model of 
SAFER’s control logic. It demonstrates that the 
two models have the same goals: rigorous descrip- 
tion and prediction of behavior but that the needed 
mathematics and calculation techniques are differ- 
ent. 

In [1, 2] Agerholm & Larsen have proposed 
a. cheaper testing based validation approach to 
the SAFER, example using an executable VDM-SL 
model and the IFAD VDM-SL Toolbox [10, 7, 6]. 
They recommend the use of a specification executor 
and animator for raising the confidence in a formal 
model prior to formal proving. 

We agree with Agerholm & Larsen’s arguments 
for such a “light-weight” approach to formal meth- 

1 The same holds for software developers coming from clas- 
sical engineering disciplines. 



ods in order to facilitate the technology transfer. 
Since in several industrial projects performed at 
our institute a similar experience has been made 
[9, 15, 5], one of our research areas has become the 
support of testing through formal methods [4]. 

However, neither the PVS nor the VDM-SL 
model of SAFER did take the continuous physical 
models into account. The reason is that, in gen- 
eral, today’s formal method tools are not well suited 
for supporting continuous mathematics. This paper 
shows a solution the problem. 

In the following it is demonstrated how an ex- 
plicit discrete model can be combined with the con- 
tinuous physical model for validation and anima- 
tion. With the right tool there is no reason why a 
physical model should not be included in the valida- 
tion process of a hybrid system. Just the opposite 
is the case: [1] detected several cases where the in- 
terface to a cut out automatic attitude hold (AAH) 
control unit needed further clarification. 

In this work the commercial computer algebra 
system Mathematica [16] has been used to overcome 
the gap between discrete and continuous mathemat- 
ics. A VDM-SL package has been implemented that 
allows to specify in the style of the Vienna Develop- 
ment Method (VDM) inside Mathematica. Thus, 
explicit discrete models can be tested in combi- 
nation with differential equation systems modeling 
physical behavior by solving the equations on the 
fly. Even pre- and post-condition checking is pos- 
sible. Again, NASA’s SAFER system serves as the 
demonstrating example. The VDM-SL specification 
of [2] has been taken and extended with the physics 
involved in SAFER, expressed through differential 
equations. More precisely, the physical behavior is 
movement in space, modeled by the laws for transla- 
tion and rotation — Newton’s and Euler’s equations 
for three dimensional space. 

Beside the execution (testing) of hybrid models, 
Mathematica’s front-end supports the visual valida- 
tion of such systems. The graphical user-interface 
for SAFER’s hand grip is implemented inside the 
computer algebra system as well as a scientific graph 
representing the movement of a crew-member using 
SAFER. After each control cycle, actual physical 
vectors like angular velocity or acceleration can be 
inspected together with the logical status, e.g. the 
thrusters firing. Finally, it is even possible to an- 
imate a sequence of performed control-cycles as a 
movie showing the SAFER representation flying. 

The structure of the rest of the paper is as fol- 
lows. First in Section 2 an overview of the SAFER 
system is given, which will serve as the demonstrat- 



Figure 1. SAFER thrusters. 


ing example throughout the paper. This is followed 
by a discussion of VDM-SL and its realization in- 
side Mathematica in Section 3. Then, a description 
of the discrete SAFER model is given in Section 
4. Section 5 explains the differential equation sys- 
tems modeling SAFER’s physics and the coordinate 
transformations needed. Then, Section 6 introduces 
to the hybrid model and demonstrates the integra- 
tion of VDM-SL and differential equation systems. 
Next, the validation capabilities of our approach are 
discussed in Section 7 and Section 8. In the final 
Section 9 we draw some conclusion regarding the 
presented work in particular, as well as possible fu- 
ture approaches in general. 

2 The SAFER System 

The following overview of the SAFER system is 
based on, and partly copied from, the NASA guide- 
book [11], which describes a cut-down version of a 
real SAFER system. 

The Simplified Aid for EVA Rescue (SAFER) is 
a. small, self-contained, backpack propulsion system 
enabling free-flying mobility for a NASA crewmem- 
ber engaged in extravehicular activity (EVA). It is 
intended for self-rescuing on Space Shuttle missions, 
as well as during Space Station construction and op- 
eration, in case a crewmember got separated from 
the shuttle or station during an EVA. This type of 
contingency can arise if a safety tether breaks, or 
if it is not correctly fastened. SAFER, attaches to 
the underside of the Extravehicular Mobility Unit 



(EMU) primary life support subsystem backpack 
and is controlled by a single hand controller that 
is attached to the EMU display and control mod- 
ule. Figure 1 shows the backpack propulsion system 
with the 24 gaseous-nitrogen (GN?) thrusters, four 
in each of the positive and negative X , Y and Z 
directions. For example, the thrusters denoted by 
5-F1, 6-F2, 7-F3 and 8-F4 are firing backwards (indi- 
cated by the arrows) resulting in a forward motion. 

The main focus of the discrete specification is 
on the thruster selection logic, which is rather com- 
plex due to a required priorization of hand controller 
commands. Various display units and switches 
which are not directly related to the selection of the 
thrusters have been ignored in our model. However, 
in contrast to [11] and [1] the calculation of the con- 
trol output in the Automatic Attitude Hold (AAH) 
is not ignored, but simulated based on a dynamic 
model of the physics discussed in Section 5. 
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Figure 2. Hand controller module of 


The hand controller, shown in Figure 2, is a 
four-axis mechanism with three rotary axes and one 
transverse axis using a certain hand controller grip. 
A command is generated by moving the grip from 
the center null position to mechanical hard-stops 
on the hand controller axes. Commands are ter- 
minated by returning the grip to the center po- 
sition. The hand controller can operate in two 
modes, selected via a switch, either in translation 
mode, where X (forward-backwards), Y (left-right), 
Z (up-down) and pitch commands are available, or 
in rotation mode, where roll, pitch, yaw and X 
commands are available. The arrows in Figure 2 
show the rotation mode commands. Note that X 
and pitch commands are available in both modes. 


Pitch commands are issued by twisting the hand 
grip around its transverse axis, while the other com- 
mands are obtained around the rotary axis. 

A push-button switch on top of the grip initiates 
and terminates AAH according to a certain proto- 
col. If the button is pushed down once the AAH is 
initiated, while the AAH is deactivated if the button 
is pushed twice within 0.5 seconds. 

As mentioned above there are various priorities 
among commands that make the thruster selec- 
tion logic rather complicated. Translational com- 
mands issued from the hand controller are priori- 
tized, providing acceleration along a single transla- 
tional axis, with the priority A' first, Y second, and 
Z third. When rotation and translation commands 
are present simultaneously from the hand controller, 
rotations take higher priority and translations are 
suppressed. Moreover, rotational commands from 
the hand grip take priority over control output from 
the AAH, and the corresponding rotation axes of 
the AAH remain off until the AAH is reinitialized. 
However, if hand grip rotations are present at the 
time when the AAH is initiated, the corresponding 
hand controller axes are subsequently ignored, until 
the AAH is deactivated. 

In [1] it is explained how a specification inter- 
preter tool facilitates the validation of the require- 
ments listed in the appendix of the NASA guide- 
book. Moreover, it is demonstrated that formal val- 
idation techniques uncover open issues in informal 
requirements even if they seem to be straightfor- 
ward and clear. 

The same validation techniques as discussed in 
[1] can be applied in our Mathematica based frame- 
work — and more. However, before we discuss the 
value added through a hybrid model, in the follow- 
ing section, the realization of our VDM-SL package 
is discussed. 

3 VDM-SL in Mathematica 

VDM-SL is the specification language of the Vi- 
enna Development Method (VDM) [10, 7]. VDM 
is a widely used formal method, and it can be ap- 
plied to the construction of a large variety of sys- 
tems. It is a model-oriented method, i.e. its for- 
mal descriptions (specifications) consist of an ex- 
plicit model of the system being constructed. More 
precisely mathematical objects like sets, sequences 
and finite mappings (maps) are used to model a 
system’s global state. Additional logic constraints, 
called data-invariants, allow one to model informal 
requirements by further restricting specified data- 



types. For validation purposes the functionality 
may be specified explicitly in an executable subset 
of VDM-SL. In addition, pre- and post-conditions 
state what must hold before and after the evalua- 
tion of a system’s operation. Although VDM-SL 
is called a general purpose specification language it 
does not support the specification of dynamic sys- 
tems. The language’s ISO-standard [13] does not 
even include standard functions like sine or cosine. 

Here, as the name indicates, Mathematica’s 
strengths supplement our combined approach. 
Mathematica is a symbolic algebra system that of- 
fers the opportunity of solving arbitrary non-linear 
as well as linear systems of equations. Mathemat- 
ica’s language interpreter is in fact a rewriting sys- 
tem providing an untyped functional programming 
language. For an introduction to functional pro- 
gramming in Mathematica see [3]. This program- 
ming language has been used in order to define a 
package emulating the specification language VDM- 
SL. By emulating we express the fact that the pack- 
age does not allow one to write specifications in 
VDM-SL’s concrete syntax, but in its abstract syn- 
tax with some pretty printing for VDM-SL output. 

Mathematica’s user interface are so called note- 
books, fancy editors structured in cells for input, 
output or plain text. Entering a Mathematica ex- 
pression in an input cell, the system tries to evaluate 
this input through a rewriting procedure based on 
pattern matching. 

The following language constructs have been 
added to the standard language in order to import 
the VDM-SL model from [2]: 

• abstract datatypes for composite types, sets, 
sequences and maps 

• comprehension expressions for sets, sequences 
and maps 

• let and cases expressions 

• operators for propositional and predicate logic 

• types optionally restricted by data-invariants 

• value and global state definitions 

• typed function/operation definitions with pre- 
and post-conditions 

Some of the items above deserve a more detailed 
discussion. 


Comprehensions 

A powerful feature of a specification language 
like VDM-SL is its ability to construct collection 
types like sets, sequences and maps through com- 
prehensions. For example, a set-comprehension de- 
fines a set through an arbitrary expression describ- 
ing the set-elements with its free variables ranging 
over a set of values, such that an optional condi- 
tion holds. The following example demonstrates 
the value added through a computer algebra sys- 
tem. The set-comprehension 

set[x|{x G Z} ■ {x 6 — 44x 5 + 318x 4 + 4102x 3 

— 4461x 2 + 550x + 8750 == 0}] 

represents a set of elements x, where x is an integer 
number such that the equation holds. 

The resulting set 2 

set[— 7, -1,25] 

demonstrates that, unlike IFAD’s VDM-SL inter- 
preter, comprehensions ranging over infinite sets 
may be evaluated. 

Types 

As already mentioned, in contrast to VDM, 
Mathematica has an untyped language. Conse- 
quently, no type checking mechanism is available. 
However, types are an important tool for specifying 
a data-model in VDM. Therefore, type declarations 
of the form Type [name, type] have been included, 
where type is one of the predefined VDM-SL types, 
like basic types, composite types, sets ... For exam- 
ple, a type ISet representing a set of natural num- 
bers might be declared by TypefISet, set[N]]. 

Optionally, a type can be further constrained by 
a data-invariant condition. Such invariant types 
are defined by Type[name, type, Invariant— > 
predicate]. The predicate is defined by a lambda 
expression mapping type to a Boolean value. All 
the invariants are globally stored in the system for 
invariant checking, before and after the evaluation 
of a VDM function. 

Internally, a type is translated to a Mathematica 
pattern, matching those values the type denotes. 
Invariant types are supported by the possibility of 
defining patterns with arbitrary predicates. These 
patterns restrict the argument range in the defini- 
tion of typed VDM functions. 

2 The six solutions including double and complex solutions 
are: -7, -1, 1 - 1, 1 + 1, 25, 25. 



Functions 

Using the VDM-SL package, typed functions 
with pre- and post-conditions can be defined using 
the constructor 

VDMFunction[id, sig, id[vars] := body, pre, post] 

with the following parameters: 

id the name of the function, 

sig the signature of the function, 

id[vars] := body the function definition, 

pre an optional pre-condition stating what must 
hold before the evaluation such that the post- 
condition holds, 

post an optional post-condition stating what must 
hold after the evaluation. 

VDMFunction realizes a complex call to Mathemat- 
ical internal Function call and emulates the checks 
for 

• the signature types, 

• pre- and post-condition, 

• data-invariants. 

4 Discrete Model 

In order to demonstrate the Mathematica pack- 
age the same functions for the thruster selection 
logic as in [1] are presented in this section. The 
six degree-of-freedom of the translation and rota- 
tion commands is modeled using a composite type: 

Type [SixDof Command, Composite [{"tran" , TranCommand} , 

{"rot", RotCommand }]] 

whose two fields are finite maps from translation 
and rotation axis respectively to axis commands. 
For example the type of translation commands is 
defined as follows: 

Type [TranCommand , TranAxis -> Axiscommand, 

Invariant -> (dom[#] == set [X , Y,Z]&)] 

where the invariant ensures that command maps 
are total. Here, the invariant predicate is defined 
by a lambda expression in Mathematica’s notation 
of pure functions. The type of rotation commands 
is defined similarly. Enumerated types are used for 
axis commands and translation and rotation axes: 


VDMFunct ion[ 

SelectedThrusters , 

AUX c SixDof Command X AUX ‘RotCommand X 
set [AUX ‘Rot Axis] X set [AUX ‘Rot Axis] 

-> ThrusterSet, 

SelectedThrusters [hem, aah, act Axes , ignHcm] := 
let [{tran, rot, bf Mandatory ,bf Optional, 

lr udMand at or y , lrud Optional ,bfThr , IrudThr} , 

{tran, rot} = 

(IntegratedCommands [hem, aah, act Axes , ignHcm] 

/. SixDofCommand[tr_ ,ro_] :->tr ,ro) ; 

{bf Mandatory , bfOptional} = BFThrusters [tran[X] , 

rot [PITCH] , 
rot [YAW] ] ; 

{lrudMandatory , IrudOptional} - 

LRUDThrusters [tran[Y] , 
tran[Z] , 
rot [ROLL] ] ; 

bfThr = If [(rot [ROLL] === ZERO), 

bfOptional U bf Mandatory, 
bf Mandatory ] ; 

IrudThr = If [(rot [PITCH] === ZERO) and 
(rot [YAW] === ZERO) , 

IrudOptional U lrudMandatory, 
lrudMandatory] ; 
set <3 <9 (bfThr U IrudThr) 

] 

]; 


Figure 3. The SelectedThrusters function. 


Type [AxisCommand, NEG I ZERO I POS] ; 

Type [TranAxis, X | Y | Z] ; 

Type [Rot Axis , ROLL | PITCH | YAW] 

In the SelectedThrusters function in Fig- 
ure 3 grip commands from the hand controller 
(with six-degree-of freedom commands) are in- 
tegrated with the AAH control output. The 
IntegratedCommands function prioritizes hand con- 
troller and AAH commands. 

Based on these commands, thrusters for back and 
forward accelerations and left, right, up and down 
accelerations are calculated by two separate func- 
tions. Figure 4 presents cut-down versions of these 
functions. These represent a kind of look-up ta- 
bles, modeled using cases expressions. Note that 
they return two sets of thruster names, represent- 
ing mandatory and optional settings respectively. 

5 Physics Involved in SAFER 

This section presents the continuous model of 
the physics involved in our hybrid model. For the 
SAFER example, translation and rotation equations 
from mechanics are sufficient for modeling the mo- 
tion of a crewmember using the propulsion system. 
The purpose of this model is twofold: First, we need 
to calculate the sensor inputs of angular velocity for 
simulating the AAH. Second, in order to visualize 




tions are then given by 

U D| + (I-.i — h)^2^3 = Qi (2) 

J 2 O 2 + (II ~ -?3)^3^1 = Q 2 (3) 

I'i&'i + (I 2 — Il)CllO ,2 = Q 3 (4) 

or as a vector equation where I is a diagonal matrix: 

I-(l + S}xI-fl = Q (5) 

Qi denotes a torque causing a rotation around the 
Taxis, in the body’s own coordinate system. Here, 
the torque is given by the sum over the thrusters fir- 
ing. Actually, a component Q th is calculated by the 
cross product of a thruster’s position vector relative 
to the center of mass and its force. SAFER does not 
use proportional gas jets, but thrusters whose valves 
are open or not, which simplifies the calculation. 


Figure 4. Extracts from BFThrusters and 
LRUDThrusters. 


the SAFER movement, absolute coordinates have 
to be determined. The mathematics needed can be 
found in the standard literature of mechanics, like 
[ 8 ], 

Translation 

The translation of a crewmember wearing 
SAFER is described by Newton’s second law of mo- 
tion expressed by 

F = mv = p (1) 

where F, m, v and p denote force vector, mass, 
velocity vector and impulse vector. It states that 
“The time rate of change of the momentum of a 
particle is proportional to the force applied to the 
particle and in the direction of the force.” 

Rotation 

The rotation is modeled by three equations 
known as the Euler’s equations of motion for the 
rotation of a rigid body. 

Denote by fl the angular velocity defined with re- 
spect to the center of mass, and by I the moments where D\ and D 3 are rotation matrices that turn 

of inertia. The equations describing the body rota- the coordinate system by a given angle. 


1 0 0 
0 cos 9 sin 9 

0 — sin 9 cos 9 


Motion 

In order to combine translation and rotation in a 
single model of motion, suitable for our purposes, 
coordinate transformations are necessary. More 
precisely, the fixed coordinate system values for vi- 
sualization (position and velocity) have to be related 
to SAFER’s coordinate system values (angular ve- 
locity). 

As 0 is calculated in the body’s own coordinate 
system, they have to be transformed back to the 
fixed coordinate system. Given the Euler angles ip, 
9 and V’ that denote the deviation of the fixed x, y 
and 2 axis, the angular velocities can be calculated 
according to the following formula. 

Di = (p sin Osin ip + 9 cos ip (6) 

D 2 = ipsinOcosip — 9 simp (7) 

O3 = ip cos 9 + ip (8) 

The derivation of these equations can be found in 
[8]. Using vector notation we get the equation: 

n = D 3 wo • A (9) ■ (0, 0 , <p) T + (0, 0 , i>) T (9) 





D\ and D 3 are used to transform a vector from 
our fixed coordinate system to a turned coordinate 
system. For translation motion, the thruster’s force 
vector F has to be transformed from SAFER’s coor- 
dinate system to the fixed one using the transposed 
rotation matrices: 

(D 3 W0 • D 1 (0) ■ D 3 (<p)) T 

Summarizing, these four vector differential equa- 
tions are sufficient for modeling SAFER’s motion 
over time: 


V - 

= X 

(12) 

m 

■v = (D 3 (tP)-D 1 (6)-D 3 (ip)) T F 

(13) 

/• 

fl + ftxIQ = Q 

(14) 

ft 

= fl 3 W)'Di(«)'(«,0,# + (0,Oi) T 

(15) 


Solving these equations with given thruster forces 
results in SAFER’s position vector x(t) and the an- 
gular velocity Cl(t) used for AAH. 

Alternatives to the Euler’s equations model are 
possible. For example, an aproach could have in- 
volved the less computationally intensive quater- 
nions. However, for validation purposes the model 
should be as intuitive as possible, here efficiency 
plays a minor role. 

6 A Hybrid Model 

The hybrid model of SAFER consists of the hand 
controller and the Automatic Attitude Hold as its 
discrete parts on one side and the equations of mo- 
tion as the continuous part on the other side. Both 
are modeled in Mathematica, the first in the form of 
the VDM-SL specification using our VDM-SL em- 
ulation package, the later in the form of ordinary 
differential equations in Mathematica notation. 

The combination of the discrete control system 
and the continuous physical model during the test- 
ing phase carries certain advantages: 

Not only can the system specification be tested 
in an (idealized) physical simulation, but also the 
system parameters like the force of the thrusters and 
the moments of inertia of the backpack can easily be 
adjusted until the system responds in a way suitable 
for practical use. 

This is not a very rigorous approach, and it is not 
intended to replace other testing tools and meth- 
ods. Rather it can serve as a valuable supplemen- 
tary tool. 


VDMFunct ion [ 

ControlCycle , 

SwitchPositions X HandGripPosition X 

Rot Command X Inert ialRef Sensors -> Thruster Set, 

ControlCycle [SwitchPositions [mode_ , aah_] , rawGrip , 
aahCmd, IRUSensors] := 

let[{ 

gripCmd=HCM ‘GripCommand [rawGrip , mode] , 
thrusters=SelectedThrusters [gripCmd , aahCmd , 
AAH c ActiveAxes[] , AAH‘ IgnoreHcm[]] 

}. 

AAH ‘Transit ion[IRUSensors , aah, gripCmd, SAFER‘clock] ; 
SAFER ‘ clock=SAFER c clock+1 ; 

PosData=CalcNewPosition [thrusters] ; 
thrusters 

], 

True, 

card [RESULT] < 4 A ThrusterConsistency [RESULT] 

]; 

VDMFunct ion [ 

SensorControlCycle , 

SwitchPositions X HandGripPosition -> ThrusterSet, 

SensorControlCycle [SwitchPositions [mode_ , aah_] , 
rawGrip] := 

ControlCycle [SwitchPositions [mode ,aah] .rawGrip, 
AAHControlOut [Sensors] , Sensors ] 

]; 


Figure 5. The ControlCycle function. 


The Control Cycle 

The ControlCycle function (Figure 5) integrates 
the discrete model of hand control, thruster se- 
lection and Automatic Attitude Hold (AAH) with 
the continuous physical model of motion presented 
above. 

The Control Cycle is implemented in two differ- 
ent functions. ControlCycle takes the state of the 
hand control (switches and hand grip) as well as the 
already calculated or manually entered AAH com- 
mands and the sensor values. SensorControlCycle 
takes the values of the sensors (here simulated by 
the solutions of the equations of motion of the pre- 
vious control cycle) and determines which thrusters 
are invoked by the AAH. These are then passed on 
to ControlCycle. 

After determining the active thrusters and the 
AAH state, the differential equations are solved nu- 
merically in the CalcNewPosition function and the 
current position is updated. These results simulate 
the values measured by the sensors (with exception 
of the heat sensors, which are left out in our model) 
providing data for AAH. This part of the control 
system is completely left out in [1] and only included 
in the form of two unspecified functions in the PVS 
model [11]. 

Here the SAFER, state is not as trivial as in [1] 
where it holds only a clock variable. 




VDHFunction[ 

AAHControlOut , 

InertialRef Sensors->RotCommand , 

AAHControlOut [IRUSensors] := 
let [{rr=IRUSensors. "RollRate" , 

pr=IRUSensors . "PitchRate" , 
yr=IRUSensors . " YawRate"} , 

map [ 

ROLL->Which[ 

rr < -EpsRoll,POS, 
rr > EpsRoll, NEG, 

True , ZERO] , 

]] 

]; 


Figure 6. The Bang Bang algorithm for 
AAH. 


State [SAFER, 

Type [clock, N] , 

Type [PosData, PositionData] , 

Type [Sensors , InertialRef Sensors] , 

Type [step, Rpos] , 

Type [PosDataLi st , List [PositionData] ] , 
init [SAFER] := SAFER [0, 

PositionData[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], 
InertialRef Sensors [0, 0, 0, 0, 0, 0, 0, 0, 0], 

1/4, {{{0, 0, 0}, {0, 0, 0}, {0, 0, 0}, {0, 0, 0}}}] 

]; 

The state above also includes the current posi- 
tion, Euler angles and velocities stored in a variable 
of type PositionData. 

Even the past position data is stored for provid- 
ing full information about SAFER’s trajectory. For 
simulation this data will be used to display the his- 
tory as a Mathematica ’’movie” showing the astro- 
naut flying around in the coordinate system. 

Automatic Attitude Hold (AAH) 

Simulating the measured sensor values by the re- 
sults of the equations of motion provides the op- 
portunity of including the Automatic Attitude Hold 
mechanism by a simple Bang Bang [11] algorithm: If 
the angular velocity for an axis where AAH is turned 
on exceeds a certain threshold, selected thrusters 
are fired in order to slow down this rotation (Fig- 
ure 6). AAH is limited to this mechanism because 
SAFER is only based on simple thrusters with two 
states: on and off. 

The Differential Equations 

The equations of motion used to determine the 
new position of the astronaut are Newton’s and 
Euler’s equations described above. Although this 


model neglects any gravitational forces and other 
disturbing influences, they could easily be added by 
an additional acceleration in the equations or ran- 
dom fluctuations applied to the results of the differ- 
ential equations. 

The new position is obtained by numerically solv- 
ing the equations rather than algebraically which is 
less time-efficient, beside the fact that the algebraic 
solution is not necessary as only the result at time 
step is needed for simulation. 

Since the equations are only slightly coupled, 
they can be solved in four steps, which is numeri- 
cally more stable than solving them all at once. This 
functionality is provided by Mathematica’s NDSolve 
function, which takes the differential equations and 
the initial conditions and returns numeric functions 
that approximate the exact solutions of the equa- 
tions. In this case the trajectory is calculated piece- 
wise: in every control cycle the trajectory only for 
that cycle is solved using the position before the cy- 
cle as the initial conditions and the force and torque 
applied by the thrusters as parameters. These can 
easily be calculated, the force by a simple vector ad- 
dition of the forces applied by every single thruster, 
and the torque by adding up the cross products of 
the thruster positions with the force applied by that 
thruster. 

First, Euler’s equation in the astronaut’s coor- 
dinate system is solved giving the angular velocity. 
This needs the forces and the torque applied by the 
fired thrusters as parameters. The result is then 
transformed back to the fixed coordinate system 
and used to solve the differential equation for the 
Euler angles. In a third step Newton’s equation can 
be solved using the results from the previous equa- 
tions. Finally, a simple integration of the velocities 
gives the position of the astronaut. 

These numerical solutions to the differential 
equations can also be used to investigate stability. 
In the simplified case without any external forces 
like gravitation, this might not be so interesting, 
but as soon as external forces are modeled into the 
differential equations, stability is a crucial concern. 
What happens if the hand controller keeps in the 
same position over a long period of time? Such 
questions can easily be answered by solving the dif- 
ferential equations for a time period longer than just 
the control cycle. 

7 Simulating SAFER 

Mathematica does not only provide algebraic and 
numeric functionality, but also an extensive reper- 




toire of plotting functions. Thus Mathematica has 
also been used to visualize SAFER’s current posi- 
tion together with other state information. 
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Figure 7. The GUI for the hand controller. 


An interface to the hand controller similar to that 
in [2] is provided in Mathematica (Figure 7). It 
contains buttons for all the hand controller states 
as well as for manual input of the AAH output for 
overriding the simulated AAH in the model. 

Pressing one of the buttons sets a global variable 
that is used to determine the parameters passed to 
the ControlCycle function. Additionally, the ”Cy- 
cles=l” button determines how many control cycles 
should be evaluated when the ” Run Control Cycle” 
button is pressed. 

Pressing ’’Run Control Cycle” initiates the con- 
trol cycle and after calculating the new position 
prints out a plot of the astronaut’s path so far to- 
gether with his orientation indicated by the axes of 
his own coordinate system (Figure 8). Additionally, 
his velocity and angular velocity are shown as vec- 
tors. Optionally a table with the list of the fired 
thrusters as well as the axes where AAH is turned 
on is printed. 

Since all the previous position data is stored, 
Mathematica can even animate this graph so that 
one can inspect the SAFER moving through space. 

A graphical interface to the simulation like in 
Figure 7 is interesting when testing the system’s be- 
havior in general. However, when adjusting param- 
eters or testing specific cases, it’s more convenient 
to run the control cycles directly using Mathemat- 
ica input commands. Figure 9 shows the input to 
create Figure 8. 

In [1] the visualization is done outside the 
toolbox using dynamic link modules, which are 
programmed specifically for this one application. 
In Mathematica, changing only the differential 
equations suffices to include other influences like 



Figure 8. A sample trajectory of the 
SAFER. 


gravity, as Mathematica chooses the algorithm to 
solve the equations. 

However, testing in Mathematica is not restricted 
to graphical simulation. Like in [1], the output of 
the thruster selection logic can be validated by enu- 
merating all possible states of the Hand controller, 
or in an extended version enumerating all possible 
states of the hand controller and the AAH. Fig- 
ure 10 shows these functions formulated in Math- 
ematical VDM-SL notation. On every possible 
state, ControlCycle is applied to calculate the fired 
thrusters. The result of this large map comprehen- 
sion then has to be investigated manually. 

Another important part in the process of veri- 
fying software would be coverage testing, which is 
unfortunately not possible in Mathematica. 

8 Enhanced Analysis of the System 

The simulation possibilities described in the last 
section can be exploited for risk and safety analysis 
of the system. A very simple application is the case 
when one of the thrusters fails due to a mechanical 
defect or an iced valve. The most important ques- 
tions in this scenario are whether the astronaut will 
still be able to navigate the system, and whether it 
is possible to return before the air or the nitrogen 
for the thrusters is used up. 

We investigated the functionality of AAH in the 
case where one thruster (6-F2) fails. Figure 11 
shows the angular velocity of the system, with the 




ResetSAFERPosition[ ]; 

(* 1 right *) 

Do [SensorControlCycle [SwitchPositions [TRAN, UP] , 
HandGr ipPosition [ZERO , ZERO , POS , ZERO] ] , {1}] ; 

(* 3 yaw *) 

Do [SensorControlCycle [SwitchPositions [ROT, UP] , 
HandGr ipPosition [ZERO, ZERO, POS, ZERO] ], {3}] ; 

(* 15 "right" *) 

Do [SensorControlCycle [SwitchPositions [TRAN, UP] , 
HandGr ipPosition [ZERO , ZERO , POS , ZERO] ] , {15}] 

(* wait *) 

Do [SensorControlCycle [SwitchPositions [TRAN , UP] , 
HandGr ipPosition [ZERO, ZERO, POS, ZERO] ] , {2}] ; 

(* 3 up *) 

Do [SensorControlCycle [SwitchPositions [TRAN , UP] , 
HandGr ipPosition [POS, ZERO, ZERO, ZERO] ], {3}] ; 

(* 6 down *) 

Do [SensorControlCycle [SwitchPositions [TRAN , UP] , 
HandGr ipPosit ion [NEG, ZERO, ZERO, ZERO] ], {6}] ; 

(* 5 up *) 

Do [SensorControlCycle [SwitchPositions [TRAN , UP] , 
HandGr ipPosit ion [POS, ZERO, ZERO, ZERO] ], {5}] ; 

(* nothing, just keep floating in space *) 

Do [SensorControlCycle [SwitchPositions [TRAN , UP] , 
HandGr ipPosition [ZERO , ZERO , ZERO , ZERO] ] , {6 } ] 

(* finally, 2 down *) 

Do [SensorControlCycle [SwitchPositions [TRAN , UP] , 
HandGr ipPosition [NEG , ZERO , ZERO , ZERO] ] , {2}] ; 


VDMFunction[ ControlCycleTest , 

SwitchPositions X HandGr ipPosit ion X Rot Command -> 
ThrusterSet , 

ControlCycleTest [SwitchPositions [mode_ , aah_] , rawGrip, 
aahCmd] := 

SelectedThrusters [HCM c GripCommand[rawGrip , mode] , 
aahCmd, AAH ‘Active Axes [] , AAH‘ IgnoreHcm[]] , 

True, 

card [RESULT] < 4 A ThrusterConsistency [RESULT] 


VDMFunction[ BigTest, 

{}-> (HCM‘ SwitchPositions X H CM ‘HandGr ipPosit ion X 
AUXIL ‘ Rot Command -> ThrusterSet), 

BigTest []:= map[ ({switch, grip, aahLaw}-> 
ControlCycleTest [switch, grip, aahLaw])| 
{switchEswitchPositions f gripEgripPositions , 
aahLawEallRot Commands }] 

] 

VDMFunction[ HugeTest, 

{}-> (HCM‘ SwitchPositions X HCM‘HandGripPosition X 
AUXIL ‘Rot Command -> ThrusterSet), 

HugeTest []:« map[({switch, grip, aahLaw}-> 
ControlCycleTest [switch, grip, aahLaw])| 
{switchEswitchPositions , gripEallGripPositions , 
aahLaw E allRot Commands } ] 


Figure 9. The commands to create the sam 
pie trajectory. 


hand grip set to forward acceleration. Just be- 
fore cycle 4 is initiated, thruster 6-F2 breaks, which 
would be used in this acceleration. This leaves 
thruster 7-F3 applying an additional torque to the 
system, which results in an increasing angular ve- 
locity. In cycles 9 and 10 the astronaut initiates 
AAH, but keeps the forward acceleration (cycles 10 
to 17 and 20 to 25). AAH is now only able to com- 
pensate the additional torque, but not to reduce the 
angular velocity. Only when the forward accelera- 
tion is turned off (cycles 17 to 20 and 25 to 30), 
AAH shows effect. 

The functionality of AAH could be improved by 
immediately excluding thruster 7-F3 from the trans- 
lational commands when thruster 6-F2 fails (and 
thus allowing thruster 3-B3 to be used by AAH in- 
stead of 6-F2). This would require a slightly modi- 
fied and more complex thruster selection logic, pro- 
viding a higher level of safety for the astronaut. 

9 Concluding Remarks 

In this article a hybrid model of NASA’s SAFER 
system has been presented using the specification 
language VDM-SL inside the computer algebra sys- 
tem Mathematica. We demonstrated that the im- 
plementation of a VDM-SL package for Mathemat- 
ica provides both, VDM-SL’s powerful language fea- 


Figure 10. The testing functions. 

tures, like comprehensions, as well as the mathemat- 
ical power of Mathematica, e.g. solving differential 
equation systems. 

The SAFER example shows the validation pos- 
sibilities of such a combined tool. Like in [1] the 
complex discrete model of the control logic can be 
validated through testing. This is a cheap technique 
for raising the confidence that the right model has 
been specified prior to the application of more ex- 
pensive formal proof techniques. 

However, with the right tool, there is no rea- 
son why the continuous models of a hybrid system 
should be excluded from validation. Such a hybrid 
validation is more suitable for finding unjustified do- 
main assumptions made in the discrete model. We 
strongly propose such validations, due to the fact 
that making wrong assumptions is the weak point 
of formal verification techniques, possibly leading to 
correct proofs of the wrong model. 

Furthermore, we demonstrated that the visual- 
ization features of Mathematica provide a conve- 
nient way to communicate a model to a customer. 
Moreover, in contrast to [1], our visualization is a 
functional graph that facilitates the communication 
to control experts as well as to customers with a 
technical expertise. 

In the Irish school of VDM, Mathematica has 
been used to explore explicit VDM specifications 
[14], but to our present knowledge not for modeling 
hybrid systems. 
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Figure 11. Angular velocity with a broken 
thruster, AAH initiated in cycle 9. 


Note that the conclusion of our work is not that 
Mathematica is the best tool for validating hybrid 
system specifications. Our Mathematica approach 
has its disadvantages, too: Our VDM-SL represen- 
tation is not as readable as the notation of standard 
VDM-SL and a typed language would be more suit- 
able for specification purposes. Rather than propos- 
ing a certain tool, our work points out the features 
a powerful toolset should provide for validating hy- 
brid systems. 

Another future approach would be the integra- 
tion of a classic formal method tool with a com- 
puter algebra system. For example a combination 
of Mathematica with the IFAD VDM-SL Toolbox 
used in [1] would be a possibility. This could be re- 
alized with the lately developed COR.BA API of this 
tool, that enables access to the toolbox as a CORBA 
object and thus calling its VDM-SL interpreter from 
programs implemented in C or Java. Mathematica 
provides an interface through its MathLink facility. 

Summarizing, we feel that our approach of hy- 
brid validation is a valuable technique for produc- 
ing systems of higher reliability and hope that it will 
stimulate further research in this area. 
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Abstract 

In life-critical and mission-critical applications, it is im- 
portant to make provisions for a wide range of contin- 
gencies, by providing means for fault tolerance. In this 
paper, we discuss the specification of a flight control sys- 
tem that is fault tolerant with respect to sensor faults. Re- 
dundancy is provided by analytical relations that hold be- 
tween sensor readings; depending on the conditions, this 
redundancy can be used to detect, identify and accommo- 
date sensor faults. 

Keywords 

Flight Control Systems; Fault Tolerance; Flight Dynam- 
ics; Sensor Failure Detection, Identification, and Accom- 
modation. 

1 Introduction 

Providing the fault tolerant capability (FTC) to control 
systems is a major issue in domains where system fault oc- 
currences may give rise to unrecoverable damages to peo- 
ple and/or to very expensive devices (e.g., nuclear plants, 
space missions, aircrafts), hi this paper we discuss mod- 
eling and specifying the fault tolerant capability of a flight 
control system (FCS), with respect to sensor faults. Rel- 
evant issues include: achieving fault tolerance for FCS’s, 
defining fault domain (i.e., specifying fault hypotheses), 
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adequate modeling, and adequate representation of the 
model. 

A typical approach to introduce fault tolerance in a con- 
trol system is physical redundancy of components. The 
detection/identification of a fault is achieved by compar- 
ing the behavior of replicated components accomplish- 
ing the same task and having the same features. Cost 
and complexity considerations led recently an increasing 
interest in alternative approaches, mostly based on an- 
alytical redundancy. Outputs of components measuring 
different but related items are observed in order to de- 
tect/identify the faulty component. We go towards the 
specification of the fault tolerant capability (based on an- 
alytical redundancy) for a FCS, bounded to sensors faults. 

We only focus on critical sensors, i.e. sensors measur- 
ing modes of the aircraft that change too quickly to be 
controlled by the pilot. We neglect multiple, transient and 
simultaneous faults. Therefore the goal of this work is 
not producing specifications for a complete fault tolerant 
capability of a real world FCS, but conceptually address- 
ing most of issues that also persist in large scale systems. 
The space of sensor readings is partitioned, under fault hy- 
potheses, and for each partition analytical relations among 
system variables are introduced in order to characterize 
the partition and to express constraints that must be sat- 
isfied when a fault occurs while system conditions fall in 
the partition, in order to guarantee stability and maneuver- 
ability of the aircraft. 

The formulation of such relations using the Software 
Cost Reduction (SCR) notation is based on the tabular 
representation of variable behavior in SCR: it is straight- 
forward to introduce the expression whose result is the 



value that a variable must assume, under given conditions. 
Functional dependency among tables is exploited to catch 
out indirect relations. On the other hand, several repre- 
sentation/execution issues are raised here on the usage of 
SCR for such a domain (e.g., modeling tune). 

Section 2 gives an overview of a FCS, in terms of hard- 
ware/software components and input/output variables. In 
Section 3 analytical relations are introduced that describe 
how analytical redundancy provides fault tolerant capa- 
bilities to a FCS; domain partition is also provided. In 
Section 4 major issues related to the SCR modeling are 
dealt, and the specification refinement process, as part of 
validation, is also sketched. In Section 5 a wider perspec- 
tive of the problem is given, as part of an ongoing project, 
where current and future possible directions are outlined. 
Conclusions are reported in Section 6. 


2 A Fault Tolerant Flight Control 

System 

2.1 Structure of a Flight Control System 

Figure 1 shows the basic architecture of a Fly-By- Wire 
Flight Control System (FBW-FCS). In FBW technology 
conventional mechanical controls are replaced by elec- 
tronic devices coupled to a digital computer. The net re- 
sult is a more efficient, easier to maneuver aircraft. Four- 
subsystems form the core of such FCS ’s. The Measure- 
ment Subsystem (MS) consists of the Sensors and the Con- 
ditioning Electronics. It measures quantities that allow 
observation of the state of the aircraft. Primary sensors 
are those sensors whose correct operation is required to 
maintain a safe flight condition. The Actuator Subsystem 
(AS) consists of the Control Surfaces, the Power Con- 
trol Units (PCU’s), and the Engines. It produces aerody- 
namic and thrust forces and moments by means of which 
the FCS controls the state of the aircraft. The Control 
Pane! Subsystem contains all control devices and displays 
through which the pilot maneuvers the aircraft. The Flight 
Control Software subsystem (FCSw) includes all software 
components of the FCS. It interfaces to the hardware of 
the FCS through A/D and D/A cards (not shown in the fig- 
ure). Current measurements, pilot inputs, and commands 
to the actuators are processed according to the Flight Con- 
trol Law (FCL) to obtain the commands to the actuators 
at the next time step. Dash blocks and arrows represent 
the system providing Analytical Redundancy based Fault 
Tolerant Capability (AR-FTC) to the FCS and will be de- 
scribed in the next section. 


2.2 Deploying Redundancy for Fault Toler- 
ance 

Any har dware or software fault within the FCS can com- 
promise the safety of the aircraft. For this reason FBW- 
FCS ’s must meet strict Fault Tolerance (FT) requirements. 
The standard solution adopted to achieve fault tolerance is 
physical redundancy. A typical multichannel architecture 
for the FCS consists of three intercommunicating FCS’s, 
that are equivalent — yet able to work independently. A 
voting mechanism checks for consistency and can, under 
some conditions, identify faulty components. Brute force 
physical redundancy is no panacea, however: product re- 
dundancy (duplicating copies of the same product) does 
not protect against design faults, and design redundancy 
(independent designs) has two major drawbacks, which 
are cost and complexity. Complexity, in turn, adversely 
affects overall reliability, and defeats the whole purpose 
of the fault tolerant scheme. This additional complexity 
affects not only the development costs, but also the main- 
tenance costs. 

These factors have, in recent years, led to an increased 
interest in alternative approaches for enhancing FCS’s re- 
liability. In the past two decades a variety of techniques 
based on Analytical Redundancy (AR) have been sug- 
gested for fault detection purposes in a number of appli- 
cations [12]. The AR approach is based on the idea that 
the output of sensors measuring different but function- 
ally related variables can be analyzed in order to detect 
a fault and identify the faulty component. Furthermore, 
preserved observability allows estimating the measure- 
ment of an isolated (allegedly faulty) sensor, while pre- 
served controllability allows controlling the system with 
an isolated (allegedly faulty ) actuator. Fault tolerance is 
achieved by means of software routines that process sen- 
sor outputs and actuator inputs to check for consistency 
with respect to the analytical model of the system. If an 
inconsistency is detected, the faulty component is isolated 
and the flight control law is reconfigured accordingly. By 
introducing AR it is possible to take off redundant sensors, 
electronics, mechanical linkages, hydraulic lines, PCU’s, 
etc., thus cutting costs and weight, and reducing overall 
complexity of the FCS. Physical redundancy would be re- 
quired only where either post-failure system observability 
and controllability are not preserved or detection of the 
fault by means of AR is not feasible in the first place. 

Application of AR in FCS’s is not new. The very same 
airplane used to conduct research on FBW teclmology 
was also used as testbed for an AR based fault detec- 
tion algorithm [14]. The algorithm showed adequate per- 
formance during flight tests. However, poor robustness 
to modeling errors and the amount of required modeling 
hampered further development. Since then, a number of 
results have been obtained in the area of robust fault de- 




Figure 1 : Fly by Wire Flight Control System. 


tection [11]. Unknown-input observers, robust parity re- 
lations, adaptive modeling, and H zc optimization are a 
few examples. Wliile recent research has enabled us to 
gain new insights into modeling analytical redundancy, 
it has fallen short of an integrated design methodology 
involving feasibility analysis, requirements specification, 
and certification of AR based fault tolerant control sys- 
tems. Exploring strengths, weaknesses, related degree of 
reduction of physical redundancy, and overall reliability 
is a fundamental step in the engineering process of such 
systems. 

3 Analytical Redundancy for Fault 
Tolerance 

3.1 The Flight Control System and Its Envi- 
ronment 

The airplane we adopt in this study is an F16. A detailed 
non-linear model of the dynamics of this airplane is pre- 
sented in [13]. The analytical redundancy of a fault toler- 
ant flight control system depends on an analytical model 
of the system and its environment. The dynamics of many 
systems can be described in terms of a set of relations 
among its inputs, outputs, states, and state derivatives. 
These relations represent constrains imposed by laws of 
mechanics, electronics, and thermodynamics upon sys- 
tem inputs, outputs, and their derivatives. Because of ne- 
glected dynamics, disturbances, and measurement errors 


the analytical model of a system is not necessarily a truth- 
ful representation of the real system. Control system de- 
signers are mindful of this discrepancy and adopt design 
techniques that are robust with respect to such uncertain- 
ties. 

In describing how analytical redundancy provides fault 
tolerance capabilities to a flight control system, we adopt 
the following notation: 

R c (state, state derivative, input, output, 

process uncertainty, measurement error) (1) 
Rd(current state, new state, input, output, 

process uncertainty, measurement error ) (2) 

Parameters involved in these relations are vectors. The 
relations are deterministic with respect to the first four 
parameters, and stochastic with respect to the last two. 
Whenever a parameter is not involved in a relation, we 
write the symbol in its place. Relation (1) is used for 
tune continuous models, where all parameters are evalu- 
ated at the same instant t. Relation (2) is used for tune 
discrete models, where all parameters are evaluated at the 
discrete time /,/., except the new state, which is evaluated 
at ffc+i. The difference [Lk+\ — tk ) is the sampling time 
of the discrete system. For the sake simplicity we describe 
only the most relevant parameters of the relations that we 
introduce in the remainder of the paper. Accordingly, we 
will often skip the description of state, state-derivative, 
process-uncertainty, and measurement-error parameters 
unless they play a prominent role in the analytical redun- 







daiicy framework. 

The following relations represent the analytical models 
of the hardware systems in Fig. 1 : 

P (x{t), x{t), c(t), x(t),£(t), -) (3) 

A(x a (t),x a (t),u(t),c{t),Z a {t),r] a (t)) (4) 

M p {x p {t),x p {t),x{t),y p {t),t p (t),T] p {t)) (5) 

M r (x r (t),x r (t),r(t),y r (t),^ r (t),T] r (t)) (6) 

Relation (3) describes the dynamics of the aircraft, i.e. 

the process to be controlled by the FCS. It involves force, 
moment, kinematics, and navigation equations. The state 
vector includes the flight variables used in the above equa- 
tions. A typical state vector is: 

* = [U, V, W, P, Q, R, 0, % PN , p E , hf (7) 

where the elements are the three linear velocities, the three 
angular velocities, the three attitude angles, and North, 
East, and altitude position of the aircraft. Forces and mo- 
ments applied to the airframe by the control surfaces and 
the engines ate included in the input vector c(t). The out- 
put coincides with the aircraft state and represents the ac- 
tual value of the flight variables in (7). Since it is a set of 
actual values, there is no output uncertainty. The process 
error vector £ is related to the uncertainty of the relation 
with respect to neglected dynamics and unknown inputs. 

Relation (4) describes the dynamics of the actuator sub- 
system. The input vector u(t) includes command signals 
to the actuators, while the output vector includes thrust 
and aerodynamic forces and moments. Relation (5) de- 
scribes the dynamics between aircraft state x(t) and pro- 
cess measurements yp(t). A typical set of sensors pro- 
vides the following measurements: 

r - - -it 

Vp — i Pt i rt, /3, A x , Ay , A z , P, Q, R (8) 

These are static pressure, total pressure, angle of attack, 
sideslip angle, body accelerations, and body angular rates 
respectively. To differentiate measured from actual body 
rates we adopt the ’tilde’ notation. Relation (6) describes 
the dynamics between the actual position of pilot controls 
r ( t ) and their measurements //,. ( / ) . The two measurement 
vectors will be referred to in the sequel as: 

y(t) = [y P {t),yr{t)] T (9) 

The following relations represent the analytical models of 
the software systems in Fig. 1 : 

I (-, y(tk), y{t k ), m{tk)) ( 10 ) 

(f k ) 5 (t &+l) ? [i/(f k ) ^ U (f k )] , U (t k-|_i ) , 

~,VL(tk)) (ID 

O ( , , u(t k ), u(tk), , ( 12 ) 


The FCSw closes tlie control loop between sensors and 
actuators subsystems. To distinguish software variables 
from related electrical signals we adopt the ’hat’ nota- 
tion. Relation (TO) represents the relationship between 
measurement samples //(//,. ) and the corresponding soft- 
ware variables y(tk)- Since this is an algebraic relation, 
there is no need to introduce state variables. r](tk) takes 
into account quantization error. Relation (11) describes 
the dynamics of the the flight control law. Current value 
of sensor measurements and actuator commands are pro- 
cessed to produce the actuator commands at the next time 
step x(t k + i ). Relation (12) describes the relationship be- 
tween software commands u ( t k ) and electrical commands 
u,(t k ). 

In order to complete the set of relationships needed to 
illustrate the principles at the basis of AR-FTFCS ’s we in- 
troduce two relationships capturing the FT requirements: 

R h (x(t),x(t),r(t),r(t)) (13) 

Ri(x(t),x(t),r(t),r(t)) (14) 

Relation (13 ) describes the high priority responsiveness 
requirements of the aircraft to pilot commands in terms 
of the true state of the airplane, the input commands, and 
then derivatives. Relation (14) describes the low priority 
requirements. For an airplane to be safe it is mandatory 
that the high priority requirements are preserved even in 
case of fault. 

3.2 The AR-FTFCS 

After having introduced the analytical model of the FCS, 
its environment, and its fault tolerant requirements it is 
possible to illustrate how an AR-FTFCS works. 

At the instant t k new measurements are available as 
software data //(/,;..). The elements of this vector are not 
independent; they are correlated by means of relations (3), 
(5), (4), (10), and ( 12). Furthermore, they are correlated to 
u(tk ) by virtue of the same relations. By analyzing sensor 
measurement and actuator command histories it is possi- 
ble to check whether the above relations are satisfied. If a 
fault within the hardware loop produces an inconsistency 
with respect to the analytical model the system is said to 
hold AR properties allowing detection of the fault. Af- 
ter detection of the fault it is necessary to identify which 
component has failed. Each component of the FCS plays 
a different role within relations (5) and (4). Hence, the 
distortion affecting these relations at the occurrence of a 
failure depends on the component failed and on the fault 
mode. By processing sensor measurement and actuator 
command histories it is possible to locate the source of 
distortion. If a fault within the hardware loop produces 
a distinct signature in terms of commands/measurements 



correlation the system is said to hold AR properties allow- 
ing identification of the fault. Once the faulty component 
component is identified, the FCS needs to be accommo- 
dated in order to preserve responsiveness requirements. 
Accommodation can be carried out at the software level 
because the flight control algorithm is not unique. Given 
relations (3), (5), (4), (10), and (12) describing the dy- 
namics of the aircraft, sensors, actuators, and interfaces 
with the FCL, there can be a number of different control 
algorithms satisfying responsiveness requirements. Some 
of these algorithms do not use all of the sensors and/or ac- 
tuators available. Hence, if a hardware component of the 
FCS fails, responsiveness requirements can be maintained 
by switching to a control algorithm that does not employ 
that component. If such an algorithm exists the system is 
said to hold AR allowing accommodation of the fault. 

Figure 1 shows how a FCS is enhanced to an AR- 
FTFCS. The dash blocks and arrows represent the sub- 
system providing Fault Tolerant Capability (FTC) to the 
FCS. The core of this subsystem is the AR-FTC software 
module, while the dash section within the Control Panel 
block represents the hardware interface to tire pilot. Fol- 
lowing the notation adopted in the previous section we 
describe the FTC subsystem by means of tire following 
two relations: 

ARsw {tC ar (t k f 'ttar{lk + 1)> \fi(fk )> h(t k ), dl(t k )] , 
[y v {tk),u v (t k+ i),v(t k ),s(t k )} , i] ar (t k )) (15) 
A-Rhw (— ) [v(tk), rn(t k )] , [rh(t k ),v(t k )] 

; t]ar{lk'}'} ( 16) 

Relation (15) describes the dynamics of the software mod- 
ule. It processes current measurements y(t k ) and com- 
mands u(t k ) to validate y(t k ) against the analytical model 
of the system. If no inconsistencies are detected the 
FCL module takes over and produces the new command 
ii(t k + 1 ). If an inconsistency is detected the AR-FTC 
module further processes incoming data to identify the 
faulty component. Then, it either produces a virtual set 
of validated measurements y v (t k ) for the FCL, or it by- 
passes the FCL and produces a new set of validated com- 
mands u v (t k +i) according to a safe control law that does 
not use the faulty component. The two options are typi- 
cally adopted for sensor and actuator faults respectively. 
If a component of the actuator subsystem fails then it is 
often necessary to reconfigure the control law to take into 
account the control deficiency. If a sensor fails its out- 
put can be estimated and the estimation substituted into 
the measurement vector y(t k ) to produce //,, (//,.). How- 
ever, the solution can be adopted where the FCL is by- 
passed and an alternative control law is used in its place. 
The s (lf ; ) signal is used to synchronize execution of the 
FCL and the AR-FTC modules. m(t k ) and v(t k ) are the 
operational mode selected by the pilot and the diagnos- 


Fault mode y, (Volts) (deg/sec) 

Loss of signal [2.0, 2.5] [—22,0] 

Loss of power 0 —90 

Loss of ground 12 90 

Table 1 : Fault modes 

tic information respectively. Relation (16) represents the 
relationship between pilot’s controls m(t k ) and displays 
v(t k ) and related software variables m(t k ) and v(t k ). 

3.3 Fault Hypotheses 

In the previous section we have shown how a system fea- 
turing AR properties can be made fault tolerant with re- 
spect to sensor faults at the software level. However, soft- 
ware along with its supporting hardware (computers, data 
buses, etc. ) and hardware systems other than sensors and 
actuators can fail as well. AR cannot be adopted to pro- 
vide fault tolerance with respect to failure of such com- 
ponents; a different approach must be adopted for these 
types of faults. 

In this phase of the study we focus our attention on sen- 
sor faults only. More specifically, we require fault toler- 
ance with respect to failure of the roll, pitch, and yaw rate 
gyros. The sensors used are a solid state rate gyro where 
a vibrating element is used to measure rotational veloc- 
ity by employing the Coriolis principle. The output range 
of the sensor is ±90deg/sec and its bandwidth is 18Hz. 
The output of the sensor has been recorded while simu- 
lating the failures. Three different fault modes have been 
considered: loss of signal, loss of power, loss of ground 
reference. The fault modes along with outputs of the sen- 
sor and the values of the correspondent software variable 
are listed in Table 1 . 

3.4 Fault Modeling 

We have to point out that even though analytical redun- 
dancy does enable us to achieve some level of fault toler- 
ance, it does not guarantee arbitrary levels of precision in 
detecting, identifying, and accommodating sensor faults. 
An exhaustive feasibility analysis covering components 
subject to failure, fault modes, and possible state evolu- 
tion for actuator, aircraft, and sensor systems is required. 
To explain how detectability and identihability problems 
arise we will refer once again to relations (3), (5), (4), 
(TO), and (12). These relations can be assembled to form 
one single relation that captures the system AR at soft- 
ware level in terms of sensor measurement and actuator 
command histories: 

Rg ([K(f k ) ; h(t k — l), • • •, — m)] i 



\y(tk)i y(tk — l)j • • • > y(tk — n)] 1 
[Htk), v(t k - 1 ), • • • , v{t k -p)]) ( 17) 

Here v represents a global uncertainty term collecting all 
process uncertainty and measurement error terms in rela- 
tions (3), (5), (4), (10), and (12). Variables n, m, and p 
represent the depths of the input, output, and uncertainty 
sequences respectively. If we consider the space whose 
points have coordinates given by the elements involved 
in relation ( 17), we can distinguish those regions of the 
space where relation (17) is satisfied, from those where 
it is not. Furthermore, we can characterize those regions 
related to distortions of relation ( 17) caused by the given 
fault modes. 

Following Mili et al. [1, 7], we model a fault toler- 
ant scheme by means of a partition of the relevant state 
space into a hierarchy of classes that represent degrees of 
correctness, degrees of maskability, and degrees of recov- 
erability. For a program, the relevant state space is the set 
defined in terms of all the values taken by all the state vari- 
ables of the program; for a set of sensors, the relevant state 
space is the set defined in terms of all file values taken by 
all file sensor readings. The partition that we derive for our 
purposes is given in figure 2. Process uncertainties (distur- 
bances, simplifying hypotheses, modeling shortcuts, etc) 
make the actual partition more complex than file original 
model [1,7]. In its current form, this partition is incom- 
plete, and is being refined. 

The inner ellipsis of figure 2 represents states for 
which the deterministic relationship within relation (17) 
holds. The outer ellipsis contains the points for which 
the stochastic relation (17) holds. Points outside this re- 
gion imply an inconsistency with the analytical model of 
the system. The three triangles marked FI, F2, and FS 
contain points related to three different fault modes. The 
intersection between the region ’FI U F2 U F 3’ and the 
outer ellipsis contains those points that are related to a 
fault mode, but that preserve relation (17). Hence, this 
region represents those states where a fault mode is not 
detectable by means of AR. This region is marked Detec- 
tion non Feasible in the figure. The region marked Identi- 
fication non Feasible contains those points for which the 
identification of a fault cannot be achieved either because 
that fault mode has not been considered within the speci- 
fications, or because failure effects do not allow us to dis- 
tinguish between the fault modes. 

To describe accommodation feasibility in analogous 
terms we need to consider the space whose points repre- 
sent the aircraft states. If after the failure of a component 
the FCL can be reconfigured to satisfy the safety require- 
ments then accommodation is feasible within the whole 
space. If instead there are states that cannot be reached 
without violating the safety requirements the space will 
be partitioned in regions where accommodation is feasi- 


ble and regions where it is not. As a limit case, accommo- 
dation is not feasible in the whole space if there is no FCL 
that would satisfy the safety requirements. 

4 SCR Modeling 

The derivation of this specification is part of a larger 
project whose purpose is to validate and certify an adap- 
tive fault tolerant capability (AR-FTC in figure 1) for a 
flight control system, which is concurrently being imple- 
mented using a radial base function neural network [8], 
Our intent is that the specification will be used as an or- 
acle in the testing task which aims to validate/ certify file 
fault tolerant capability. Consequently, it is rather imper- 
ative that die specification be written in a language that 
is supported by automated tools; so that in the validation/ 
certification phase, the neural net and the executable spec- 
ification can be executed independently to provide a basis 
for checking the former against the latter. We have chosen 
to use SCR as the specification vehicle, because it lends 
itself to this type of application: tabular representations, 
which form file semantic foundations of SCR, were used 
in [3] to specify file requirements of file Navy’s A7-E air- 
craft and in [10] to specify nuclear power plants; SCR 
was used to specify an autopilot [2], to specify a variety 
of high assurance applications [5, 6], and to specify some 
functions of Hie space shuttle software [15]. 

4.1 Scope of the Specification 

Figure 1 shows the structure of the overall aircraft sys- 
tem, including the data flow between the aircraft, the flight 
control system, the cockpit controls, and the environment. 
The first issue we must address is to delimit the bound- 
aries of our specification. We have pondered two possi- 
ble options, which we denote by option 1 and option 2: 
whereas option 1 focuses on the inputs and outputs of file 
fault tolerant capability component (re: AR-FTC, in figure 
1), option 2 (the aggregate of the flight control system, 
with the aircraft) considers the impact of file outputs of 
the AR-FTC on the aircraft state. The choice of an option 
is driven by the following considerations. 

• Generality/ Abstraction. For a given situation, de- 
fined by a set of sensor readings, there are many se- 
quences of actions that a flight control system can 
follow to achieve/ maintain the maneuverability/ sta- 
bility of the aircraft. At any instant, these actions 
may be different, but their combined effect over time 
is identical. Hence by virtue of abstraction (we do 
not wish to deal with the detailed mechanics of how 
the AR-FTC operates) and generality (writing speci- 
fications that apply across a wide range of possible 
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Figure 2: Partition of the Space of Sensor Readings 


implementations), the second option is better than 
the first. 

• Observability/ Controllability. If we choose option 
2, then we cannot judge the outputs of the AR-FTC 
directly, but we have to observe their effect on the air- 
craft. This gives us much lower observability of the 
AR-FTC than option 1. Controllability is the same 
for both options. 

Ultimately, this decision amounts to choosing between 
observability (option 1), i.e. the ability to observe and 
monitor the exact values that are produced by the FTFCS 
implementation, and abstraction (option 2), i.e. the ability 
to give the implementer some latitude in how to maintain 
maneuverability. We have ruled in favor of abstraction. 

4.2 Representation Issues 

By virtue of the choice discussed above, the input vari- 
ables of the specification are the sensor readings of rel- 
evant flight parameters (altitude, speed, acceleration, an- 
gle of attack, rate gyros, aileron deflections, elevator de- 
flections, rudder deflection) and the actuator input values; 
the output variables are the actual values (i.e., the vali- 
dated vectors ) of the same parameters and a fault report. 


Hence, for parameter Y, for example, we define var iable 
mY (named after SCR parlance: monitored Y) which rep- 
resents the sensor reading for Y , and variable cY (con- 
trolled Y ) which represents the actual value of par ameter 
Y . Because of sensor failures, cY may differ from mY . 
In addition, because of the latency of the FCS and (espe- 
cially) of the aircraft (in reacting to adjusted actuator val- 
ues), the value of cY at time / (cY (/)) is not functionally 
related to the value of ml' at the same time t (mY (/)), 
but rather to previous values of mY. In addition to the 
sensor readings of the flight par ameters, the set of input 
var iables also includes the values of the cockpit controls. 
The second and fourth columns of table given in figure 3 
show the structure of the input and output spaces. We now 
give a mapping of those spaces into the partition of sensor 
readings in figure 2. 

The innermost ellipsis of figure 2 represents the fault- 
free case, whose relation takes the form 

R = {((mY, mil), (cY, cU))\p(mY, mil, cY, cU)}, 

where predicate p characterizes the condition of determin- 
istic fault freedom. The outermost ellipsis of figur e 2 r ep- 
resents the case in which a measurement error in sensor 
readings leads to uncertainty in the fault process; the r ela- 
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tion for this ellipsis takes the form 

R' = {({mY,mU),(cY,cU))\q{mY,mU,cY,cU,r 1 ,Z)}, 

where 7 ; represents the measurement error and £ the pro- 
cess uncertainty; predicate q characterizes the condition 
of fault status in the stochastic dynamics. 

Each triangle Fi of figure 2 represents a different fault 
mode, whose relation take the fonn 

Rf, = {((mY, mU))\fi{mY, mU)} , 

where predicate fi characterize the condition of fault 
mode i. Different shades and bold lutes in figure 2 sep- 
arate areas with different fault capabilities. In order for a 
fault i to be detected, it must satisfy 

Rf, 0=0; 

also, to be identified, it must satisfy 

Rf, D Rf, = 0 (Vj # i). 

With regard to accomodability, the specification must 
reflect the property that the aircraft remains maneuver- 
able despite the presence of sensor faults. In particular, 
in every triangle F) maneuverability is a binary function 
in variables mM R(t) and cY(t) (linking pilot commands 
to actual flight parameters). Because mM R(t) and cY(t) 
are not instant variables but rather functions of time, it is 
conceivable that the value of cY at some time / be a func- 
tion of the value of mM R at a previous time t' < t. 

4.3 Modeling Issues 

Time is inherent in the specification of the FTFCS . Execu- 
tion of the FTFCS takes place in the context of a sequence 
of sensor inputs which, except for faults, represents a 
physically feasible flight path. The FTFCS is aware of 
the passage of tune through the advent of clock pulses; 


at each clock pulse, the FTFCS takes a snapshot of the 
sensor readings, processes them, computes actuator val- 
ues, then awaits the next clock pulse. Note that the sensor 
readings may well remain constant across two or more 
clock pulses; the FTFCS processes them at each clock 
pulse all file same. On the other hand, sensor readings 
may take several distinct values between two successive 
clock pulses; the FTFCS is only aware of their two values 
at the successive clock pulses. 

Whereas the real-time operation of the FTFCS is driven 
by file clock pulses, the execution of the SCR specification 
(for the putposes of validating the specification or verify- 
ing implementations against it) is driven by the succes- 
sive application of the functions defined by SCR’s tabular 
expressions on the input variables and the state variables. 
SCR specifications are executed in a kind of a batch mode, 
where the real tune between two successive function ap- 
plications need not bear any relation to the actual time 
between two successive clock pulses. 

The concept of tune arises naturally in flight dynamics 
equations, which are differential equations of flight pa- 
rameters and pilot commands. Let us consider some con- 
trolled variable cX, and let us assume that this variable 
satisfies the following differential equation: 

^ f <*>■ 

where t is the time variable, F is a function of t that po- 
tentially involves monitored and controlled variables (in- 
cluding rA ), and is the derivative of A" with respect to 

tune. If we approximate the derivative by means of finite 
differences, we find A _ F(t). If we let St 

be the interval between two successive clock pulses, and 
let this be the unit of time (i.e. , Si = 1), then cX(t) and 
cX (t — St) measure the current value and the past value of 
parameter cX. Solving this equation for cX (t), we find 

cX{t)=cX(t-St) + F(t). (18) 

Each application of this transformation (from cA (t — St) 
to cX (/ ) ) represents the effect of the advent of one clock 
pulse. In order to distinguish between the current and past 
values of variable cX, we use SCR’s concept of term vari- 
able. To each flight parameter (X) we associate a term 
variable, which we denote by prefixing the variable name 
with /,; the term variable is used to represent the value of 
the variable at the preceding clock pulse. In order to rep- 
resent file transformation described in equation (18), we 
write SCR tables to perform the following transformations 
in sequence. 

tX := cX; 

CX := tX + F; 




We cannot merely define two tabular expressions that 
compute variables cX and / X according to these formu- 
las, for they produce a circular reference (and SCR does 
not recognize the sequence command — the order of ex- 
ecution in SCR is driven merely by functional dependen- 
cies). 

A tantalizing alternative is, of course, to use SCR’s 
primed variable convention, whereby the pruned version 
of any given (non-primed) variable is the previous value of 
that variable. Tins option does not work for our purposes, 
because of the specific interpretation of previous value in 
SCR. SCR is event-driven, where each change of value 
of any variable is understood to be an event; by contrast, 
our model is time-driven, where an event is the advent of 
a clock pulse. If, between two successive clock pulses, 
three monitored variables change values, SCR considers 
that it has witnessed three events, and prev ious refers to 
the most recent one; by contrast, our model considers that 
only one event has occurred, and previous refers to the 
state of the system at the previous clock pulse. 

5 Assessment 

In this section, we review our specification project (al- 
though it is still in progress) and assess some of our deci- 
sions, with partial hindsight. 

5.1 SCR Adequacy 

We briefly report on our experience with using SCR for 
the purposes of our specific situation. We acknowledge 
that we have very little prior experience with SCR, and 
our comments must be qualified accordingly. 

The general pattern of a table in SCR is to compute 
a controlled variable in terms of monitored variables and 
possibly term variables. Many requirements that we en- 
counter are instead best formulated as a relation between 
monitored variables (to limit the domain of a relation), or 
a relation between controlled variables (to limit the range 
of a relation). Also, even if the controlled variable is a de- 
terministic function of the monitored variables, it may be 
more natural to represent this function by a conjunction of 
non-oriented, non-deterministic, relations. 

We find it unsettling that in a specification that has a 
large number of tables, the only composition operator be- 
tween these tables is functional dependency, which is not 
even explicit. We would find it more powerful to have a 
wide vocabulary of composition operators which we can 
use to compose tables together. There is undoubtedly a 
sound basis for letting functional dependency be the sole 
criterion that determines the order of evaluation of tabu- 
lar expressions. But our experience with modeling time 
would have been more successful if we had the ability to 


impose an arbitrary sequencing between tables, to break 
the cycle of circular dependencies. (Note: It is possible to 
define a refinement -monotonic sequence like operator, us- 
ing demonic semantics). Furthermore, because tables are 
combined only with functional dependencies (rather with 
refinement-monotonic composition operators) we find no 
natural discipline for stepwise specification generation. 
Such a discipline would enable us to compose a specifica- 
tion in a stepwise maimer, and to know that as we produce 
more and more tables, the overall specification grows in- 
creasingly more refined (until completeness). The struc- 
ture afforded by such explicit composition operators can 
be used to control the complexity of subsequent validation 
and verification tasks. 

Because SCR, and the tabular expressions on which it is 
based [9, 4], support model-based specifications, it elicits 
more detail from the specifier than a behavioral specifi- 
cation. This excess detail makes the specification more 
complex, and may lead to inconsistencies. 

We find that the data type offerings of SCR are more 
akin to those of a programming language than to those of 
a specification language. In an application such as ours, 
we needed a variety of data types, ranging from angles 
(degrees) to durations (seconds) to engine speeds (rota- 
tions per minute) to positions (meters) to speeds (meters/ 
second) to accelerations (meters/ second/ second) to an- 
gular velocity (degree/ second), etc. We found ourselves 
mapping all of them into reals, when a language supported 
typing system that provided a wide range of data types and 
a corresponding type checking function would have en- 
hanced the readability and reliability of our specification. 
We also found that it would have been helpful if SCR pro- 
vided dimension-checking functions, whereby whenever 
we write an equation, it checks the dimensions of both 
sides to ensure that they are consistent. Whether this is an 
extension of the type checking function, a separate func- 
tion, or actually the same (only more elaborate) function, 
we do not know. 

Many of the issues that we raised here are interrelated 
(e.g. a single design decision dictates a host of interrelated 
issues), and many stem from legitimate design tradeoffs 
(e.g. favoring efficient executability vs expressive power). 
We assume that as we become more acquainted with the 
spirit of SCR’s specification model, some of these issues 
will may grow increasingly insignificant. 


5.2 Non-determinacy 

We faced a dilemma while trying to derive a specification 
for the fault tolerant capability flight control system, deal- 
ing with the determinacy of the specification. We had two 
options: 



Make the specification deterministic. This is more 
natural, from the standpoint of SCR (which revolves 
around the pattern of formulating controlled vari- 
ables as a function of monitored variables), and 
yields generally simpler specifications. The mam 
drawback of this solution, of course, is that it forces 
us to second guess the designer of the neural net, be- 
cause we have to derive a specification for the exact 
function that the neural net is implementing. This, 
in turn, has two drawbacks: first, it imposes much 
coordination between the implementer team and the 
specifier team, and is counterproductive from a V&V 
viewpoint (V&V relies primarily on redundancy); 
second, it imposes early constraints on the designer, 
prohibiting him from altering design decisions that 
affect file specifier team. 


Make the specification non deterministic. The posi- 
tion here is to let the specification focus on express- 
ing the desired functional properties, without going 
as far as to uniquely specify which output will satisfy 
these desired properties. This solution is consistent 
with traditional guidelines for good specification, but 
causes some difficulty in SCR, because SCR does not 
handle non-determinacy naturally. This is the most 
striking limitation we have encountered using SCR. 
In our example (and certainly in many other applica- 
tions as well), we often encounter requirements that 
are not deterministic; also, many complex require- 
ments are best formulated as the aggregate of a set of 
simpler, non-deterministic requirements. 


We felt very justified in choosing the second option, but 
have found that it raises an issue which may, with hind- 
sight, cause us to reassess our choice: Under the first op- 
tion (deterministic specification), the specification of the 
system does not have to capture the criteria under which 
differences of output between the specification and the 
implementation can be considered tolerable; this decision 
can be made during the verification and validation step, 
by the V&V team, to take into consideration any special 
circumstances that may arise at run-time. By contrast, un- 
der the second option, the tolerance margins have to be 
hardcoded into the specification, and cannot be adjusted 
subsequently by the V&V team to account for special test- 
ing/operational conditions. Hence both options force us 
to make early decisions: The first option imposes on us to 
agree with the implementer on specific design decisions; 
the second option imposes on us to agree with the V&V 
team on specific tolerance margins. 


6 Prospects 

6.1 A Testing Plan 

Our plan calls for using the target specification as an or- 
acle in the test plan of the neural network. Specifically, 
the neural net feeds its inputs into a certified flight sim- 
ulator, which plays the role of the aircraft components in 
the graph of figure 1. This aggregate is placed side by 
side with the SCR specification, whereby the SCR is used 
as an oracle to test the neural net. Input data is submit- 
ted to the system under test and the SCR oracle, to check 
for correctness. This input data is the aggregate of sensor 
readings and pilot controls, which are collected from pre- 
viously collected flight simulation data. The purpose of 
the testing plan is to make a ruling on the certifiability of 
the neural net as an implementation of the fault tolerant 
capability of the flight control system. The system struc- 
ture that we have derived for tins purpose is presented in 
figure 4. The fault reports of the neural net and the SCR 
specification ar e compared for logical equality, producing 
the result shown in the lower right comer of the figure. On 
the other hand, the actual state of the aircraft, produced by 
the flight simulator, is matched against the pilot controls 
(by virtue of a law that captures aircraft maneuverabil- 
ity), to return a boolean indicator of whether the aircraft 
maintains adequate maneuverability (despite the possible 
presence of faults). 

6.2 Interpreting Flight Dynamics Equa- 
tions 

In file process of deriving the SCR specification of the 
FTFCS system, we are really conducting two activities, 
namely modeling and representation: 

• Modeling. Tins task deals with such matters as de- 
ciding which parameters are of interest, how do we 
represent the fault tolerant capability, how do we rep- 
resent time, how do we approximate derivatives, how 
do we enforce sequencing of tabular evaluations/ ex- 
ecutions, how do we reflect the dynamic nature of 
the system, how do we detect, identify and accom- 
modate faults, etc. 

• Representation. Generally speaking, this matter 
deals with how do we map our model into SCR 
terms, and how do we formulate our model in such 
a way as to take the best advantage of built-in SCR 
features. 

Ideally, we would like to think of these two activities ar e 
being strictly sequential; i.e. modeling must be completed 
before representation can proceed. As attractive as it may 




Figure 4: A Testing Plan for the Neural Net 


be, this discipline has proven to be a challenge in prac- 
tice, due to time pressures and to the impact of represen- 
tation constraints on modeling decisions. This has led us 
to consider the possibility of producing a syntax directed 
translation of flight dynamics equations into SCR source 
code. The mam advantage of this solution is that we get to 
encode all our modeling decisions in the syntax-directed 
rules; this allows us to keep our modeling options open 
until very late in the specification lifecycle; most impor- 
tant of all, this solution ensures that our modeling deci- 
sions are applied uniformly across all the equations of the 
specification. 

6.3 Analytical Reasoning on Neural Nets 

Traditional certification algorithms observe the behavior 
of a software product under test, and make probabilistic/ 
statistical inferences on the operational attributes of the 
product (reliability, availability, etc). The crucial hypoth- 
esis on which these probabilistic/ statistical arguments ate 
based is that the software product will reproduce under 
field usage the behavior that it has exhibited under test. 
This hypothesis does not hold for adaptive neural nets, 
because they evolve their behavior (learn) as they prac- 
tice their function. Of course, one may argue that they 
evolve their behavior for the better; but better in the sense 
of a neural net (convergence) is not necessarily better in 
the sense of correctness verification (monotonicity with 
respect to the refinement ordering). Concretely, a neu- 


ral net may very well satisfy the SCR specification in the 
testing phase, and fail to satisfy it in the field usage phase, 
even though it converges. See figure 5. 

In light of these observations, we envisage to comple- 
ment the certification testing activity with an analytical 
method. Such a method would rely on some semantic 
analysis of the neural net, as well as some hypothesis re- 
garding the data that it receives in the future. 

7 Summary 

In this paper we have discussed the formal specification, 
in SCR, of an adaptive fault tolerant flight control sys- 
tem. The specification is due to be used as an oracle in 
the certification of a radial basis function neural net that 
implements the adaptive scheme. The fault tolerant prop- 
erties of the system, the adaptive nature of its implemen- 
tation, and the specific application for winch the specifi- 
cation is intended (certification), contribute to make tins 
a unique experiment in system modeling and representa- 
tion. In particular, the fact that the system implementa- 
tion is adaptive (hence does not duplicate its behavior as 
it evolves) rules out traditional testmg techniques. Also, 
the fact that the system’s behavior is dependent on input 
history precludes the traditional static analysis techniques. 
The specification generation is under way, and we expect 
many of the modeling and representation decisions that 
we have discuss in this paper to remain in flux. 
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Figure 5: Convergence does Not Ensure Consistency 
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Abstract 

We survey mathematical modeling, the mathe- 
matical and computational technologies upon which 
it relies, and the potential sources of error. We as- 
sess formal methods and computational logic in this 
light, suggesting that certain well worn paths may 
have little to offer. We identify as opportunities 
for the future: analyzing requirements, assumptions 
and proof obligations for the assessment and confir- 
mation of models, extending such techniques to ar- 
chitectures for heterogeneous distributed models with 
legacy components, using computational logic to ex- 
tend the capabilities of computer algebra systems, 
and techniques for symbolic analysis. 


1 Introduction 

The purpose of this paper is to assess formal 
methods and computational logic from the point 
of view of mathematical modeling. It forms part 
of a larger research program assessing formal meth- 
ods and computational logic for mathematics and 
its applications. 

The techniques of mathematical modeling, that 
is of regarding a physical phenomenon as a dynam- 
ical system for the purposes of understanding and 
prediction, arose in the physical sciences during the 
twentieth century, were used widely in meteorolog- 
ical and defense applications and later spread to 
environmental, biological and geological modeling. 
They were transformed by modern computation, 
and by increasing reliance on modeling in many as- 
pects of public policy, and have also become the key- 
stone of US undergraduate math curriculum reform 
[38]. This paper concentrates on the issues aris- 
ing in bioscience and environmental science, rather 
than on physical sciences, engineering or control 
theory: in particular we are considering computa- 


tional rather than physical models. 

In the first part of the paper we survey math- 
ematical modeling, the math and software that it 
relies upon, and possible sources of error and user 
concern. We go into some detail, on the grounds 
that assessing how formal methods might be used 
in practice requires a general understanding of what 
the practice of modeling is. In the second part we 
consider how formal methods and computational 
logic might address these concerns, and identify 
some possible new directions. 

Section 2 is a methodological aside. Section 
3 contains an account of mathematical modeling, 
which we encapsulate as a “purposeful representa- 
tion of reality” . A modeler devises a “model world” 
to investigate some “purpose” in the “real world”. 
A mathematical “model” of the model world is con- 
structed using dynamical systems, and the mod- 
eler reasons within it. Almost universally today the 
reasoning is done with the aid of numeric or sym- 
bolic computation, so an “implementation” of the 
mathematical model is built in a computer system: 
from the “implementation” conclusions are drawn 
about the “model” or the “model world” and as- 
sessed against the hypotheses of the “model world” 
or against observations of the “real world” . We may 
view this as a pipeline: {reality+ purposes} — > model 
world — > model — > implementation. 

Thus modeling relies on two underlying tech- 
nologies: the mathematical theories of differential 
equations and dynamical systems, and the compu- 
tational tools of numeric or symbolic computation. 

In Section 4 we give a brief account of the first 
of these, the mathematical theories. We describe 
the kind of reasoning that is typically done, and 
assess the correctness issues. We note in particular 
that the mathematician developing the theories, the 
toolsmith using them to devise algorithms and the 
modeler using those algorithms may have somewhat 
different perspectives. 



In Section 5 we consider the second technology, 
and describe numeric and symbolic computation 
and some of the correctness concerns that arise. Nu- 
merical systems are widely used because they always 
give an answer: it is suggested that general software 
engineering issues rather than bugs in algorithms or 
floating point arithmetic are the main cause of er- 
ror. Symbolic computation systems are much less 
flexible, and further problems arise because of fun- 
damental design issues which mean that continuous 
math is sometimes handled incorrectly. 

Sections 4 and 5 considered the underlying tech- 
nologies: in Section 6 we return to the model- 
ing process itself and assess correctness concerns. 
While these can arise anywhere in the pipeline, it 
is the assessment of a “model” or “model world”, 
against competitors and against purposes that at- 
tracts most attention in the modeling community, 
and in matters such as environmental prediction (for 
example, querying assumptions about ground water 
penetration) they can be subject to heated debate. 
In large or legacy models even tracking built-in as- 
sumptions can be hard. 

Section 7 addresses how computational logic and 
formal methods may address some of the correct- 
ness concerns raised in the previous sections. The 
correctness of the mathematical and computational 
technologies can in principle be addressed using 
techniques of computational logic: we indicate the 
main notions for both. In particular we report 
briefly on our own work using heavy duty theo- 
rem proving in PVS to provide convenient embed- 
ded reasoning tools for computational mathemat- 
ics systems. However we assert that in general the 
modeling community are users rather than creators 
of mathematics and software, and are not particu- 
larly concerned to have formal developments of ei- 
ther the underlying material or its applications in 
modeling, or to replace them with new foundational 
approaches: these are all regarded loosely speaking 
as “solved problems” . While in principle techniques 
based on improved forms of symbolic computation, 
or on computational logic, would allow richer rea- 
soning about models, it is hard to see them match- 
ing the flexibility of numerical systems or overcom- 
ing the investment in existing techniques. 

Correctness concerns about the modeling pipe- 
line involve, in so far as they can be formalized, 
tracking of requirements and assumptions, and here 
we judge there to be much greater potential for for- 
mal methods from the user’s point of view. We re- 
port briefly on our own experience with light for- 
mal methods for tracking requirements, assump- 


tions and proof obligations in computational math- 
ematics systems. 

In the light of the above Section 8 sets out four 
main opportunities for the future: analyzing re- 
quirements, assumptions and proof obligations for 
the assessment and confirmation of models, extend- 
ing such techniques to architectures for heteroge- 
neous distributed models with legacy components, 
using computational logic to extend the capabili- 
ties of computer algebra systems and improved tech- 
niques for symbolic analysis. 

2 A methodological note 

It would be easy enough to tell a rosy story within 
the contemporary rhetoric of formal methods and 
computational logic of their potential for mathe- 
matical modeling, illustrated with anecdotes of un- 
reliable predictions from unsound models or bugs 
in numerical code. We might then, with some ef- 
fort, treat a simple differential equation or verify a 
numerical algorithm within our formalism of choice, 
argue with the aid of a large bibliography about how 
such methods are “growing in importance”, “vital 
for safety critical applications of mathematical mod- 
eling” , “essential for mathematicians in developing 
trusted proofs” and so forth, and conclude with an 
exhortation to the academic and commercial mod- 
eling community to take up our ideas forthwith. 

We have attempted a somewhat different ap- 
proach here, by identifying, albeit informally, the 
practice and concerns of the modeling community 
and how formal methods techniques might address 
them. 

The identification of “practice” in a discipline in- 
volves finding out what people actually do, rather 
than what they say they do, or what others think 
they should do. Thus for example in [25] we showed 
that practice in pure mathematics research does 
not, as an outsider might suppose, consist in rig- 
orous formal development but rather in the devel- 
opment of “good enough” proofs: this explains why 
computational logic engines are hardly used by pure 
mathematicians. 

For sociologists such as Latour [22] identifying 
practice involves detailed observations over many 
months in laboratories, and careful enquiry as to 
whether there is any such thing as a universal 
or context-independent notion of scientific method, 
rather than “particular courses of action with ma- 
terials to hand” [24]. 

For the purposes of this paper we gained an 
overview from textbooks, university courses, meet- 



ings, seminars, newsgroups, bug-reports and dis- 
cussions with reflective practitioners, who included 
both developers and users of such software 1 . I am 
not aware of any thorough study into correctness 
concerns for modeling and what causes errors, al- 
though Mackenzie has touched on such matters in 
his sociological account of the development of nu- 
clear weaponry [24]. Certainly the matter has not 
received the attention given to safety-critical sys- 
tems. This paper can only be regarded as a pilot 
investigation: I conclude that, while certain indi- 
vidual incidents have been noted and studied, in 
general correctness is taken for granted, and where 
it is discussed it is the correspondence of models to 
reality, rather than the correctness of the underlying 
mathematics or software, that causes concern. 

3 What is a model? 


What is a model? A mathematical representa- 
tion of reality? What is reality? What is a math- 
ematical representation of it? Is it “out there” or 
“purely formal” , or constructed in the minds of sci- 
entists with all kinds of motives and purposes, in- 
cluding the quest for truth (whatever that might 
be)? Questions of this kind have occupied philoso- 
phers of science for centuries. For this paper we 
adopt a work-a-day definition based on the standard 
student text of Mooney and Swift [28]: a mathemat- 
ical model is a purposeful representation of reality 
using the tools and substance of mathematics, in- 
cluding computation. 

A classic example is the predator-prey model 
whose purpose is to understand the long-term be- 
havior of populations of predators (for example 
lynx) and prey (for example hares) which mani- 
fest cyclical behavior: as lynx numbers x rise more 
hares are eaten, so hare numbers y drop, so lynx 
numbers drop, so more hares survive, so lynx have 
more to eat, so lynx numbers increase, and so on. 
This is modeled by two differential equations, where 
a, /?, 7 , d represent parameters which will vary for 
different populations. 


dx 
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We call this Model PP1. From these equations we 
may prove that y a e~ 0v . v J e~ Sy = K and hence de- 
duce that in the model x and y do indeed manifest 
cyclical behavior over time for certain values of the 
parameters. Even without this analytic formula we 

1 See acknowledgements section for more details 


can implement the equations numerically and hence 
draw graphs of x , y and t to display the cyclical be- 
havior. 

A simple account of modeling considers “the real 
world” (including hare and lynx), a “purpose” (un- 
derstanding population change in hare and lynx), 
the “model world” consisting of assumptions we 
have made or chosen about the real world (for exam- 
ple that lynx die when there are no hares to eat), the 
mathematical “model” we have built of our model 
world using dynamical systems , 2 and the “imple- 
mentation” of that model in a computer system. 
From the “model” or its “implementation” we can 
draw conclusions about the “model world” which we 
can then assess against the hypotheses of the model 
or against experimental or other understanding of 
“the real world”. We may view this as a pipeline: 
{reality+ purposes} — t model world — t model — t im- 
plementation. 

The predator-prey model PP1 above is an ab- 
straction, whose purpose is to investigate the ap- 
parent cyclical nature of such populations. It tells 
us that if the hypotheses in the model world about 
the behavior of hare and lynx are satisfied, and 
if a, (5, 7 , 8 take certain values, then certain conse- 
quences ensue in the model, and hence by implica- 
tion in the “model world” . We may then use domain 
knowledge to give an interpretation of our conclu- 
sions for “the real world” . 

If we wanted to study a particular population of 
hares and lynx this model would not be of much 
use. We would need a different “model world” and 
a more complicated “model”, which we denote by 
PP2. We would take other phenomena into account, 
for example what hares eat, and consider data, ei- 
ther real or simulated, on weather patterns or grass 
growth for our particular population. We would 
probably no longer have an analytical solution, and 
would have to rely on an “implementation” to ob- 
tain numerical, graphical or visual estimates for long 
term behavior. These estimates would still be con- 
tingent upon our assumptions, and the nature and 
quality of the data, we used. PP2 might not man- 
ifest cyclical behavior at all: it might not include 
the equations of PP1. The mathematical relation- 
ship between our two models might be complex: it 
would be unlikely that, in formal method terms, 
one was a simple refinement of the other for in- 
stance. The distinction between these two kinds of 
model, roughly speaking the first more concerned 
with abstract principles or putative laws of nature, 

2 For the purposes of this paper we ignore stochastic and 
discrete aspects 



the second with simulations and predictions of phe- 
nomena, has sometimes been drawn by calling the 
former “models” and the latter “simulations” . How- 
ever there is no hard and fast distinction. 

Both PP1 and PP2 are, in modeling terms, fairly 
small and straightforward, in contrast to global 
models of climate or population, refined over many 
years with complex data sets. 

Once we have a model, or several models, we may 
investigate their solution and other properties, ei- 
ther mathematically or through an implementation. 
Models are assessed and evaluated against their pur- 
poses, or against other models that address the same 
or related purposes. Of particular concern is the 
definition and assessment of correctness. 

4 Mathematical techniques 

The theory 

In this section we give a summary of some of the the- 
ory of differential equations and dynamical systems 
from the point of view of mathematical modeling 
applications. 

What do we mean by a differential equation, and 
a solution? At an elementary level in a modeling 
text such as Mooney and Swift [28] the notion is 
often given only by example: for instance suppose 
we wish to model the motion of a particle in terms 
of the time and distance from an initial point (y) 
and the acceleration (y" = d 2 y/dt 2 ). The equation 

y"(t) + y(t) = 0 (2) 

describes the motion at time t, any solution has the 
form (p(t ) = Asin(t ) -I- Bcos(t ) where A and B are 
arbitrary constants, and a solution satisfying the 
initial conditions y(0) = l,t/'(0) = 2 is given by 
<f>(t) = 2 sin(t) + cos(t). A solution satisfying the 
initial conditions can be evaluated at any value of t, 
so that for our solution </> at time t = 7t/2 the posi- 
tion will be given by <^>(7 t/ 2) = 2. This equation has 
an explicit mathematical solution (we call this an 
analytic solution), but for many equations we may 
know only of the existence of such solutions, and 
numerical solutions at particular points (subject to 
the accuracy constraints of numerical analysis) may 
be all that are available to us. 

“Solving” an equation involving an unknown 
function y and its derivatives, and conditions on the 
value of y at certain points, involves finding a partic- 
ular (some possible such y) or a general (all possible 
such y) analytic solution in terms of known func- 
tions. In texts at the level of [28] various standard 


“cook-book” techniques are given, accompanied by 
reassurance and motivation for the reader. There is 
also particular stress on determining the qualitative 
or limiting behavior of the solution: does it decay 
over time for example. 

Thus for example [28] contains the following 
recipe for solving first order linear differential equa- 
tions of the form 

^ + a(x)y = b(x) : (3) 

the general solution is (sic, including sloppy variable 
naming) 

y (x) = — ^y( J p{x)b(x)dx + C ) (4) 

where n(x) = exp (f a(x)dx). This description elides 
many issues concerned with exactly when functions 
are defined or differentiable, or solutions exist. The 
standard approach of an undergraduate course in 
differential equations makes matters more precise: 
Suppose that a and b are continuous functions on an 
interval I. Let A(x) be a function such that dA/dx = 
a(x). If C is any constant then the function <j) given 
by 

X 

</>( x) — exp(-A(a;))( J exp (A(t))b(t)dt + C ) (5) 

Xo 

where Xo is in /, is a solution of (3), and every 
solution has this form. 

The standard treatment continues by considering 
existence proofs for solutions. A particularly impor- 
tant class is that of linear systems, of the form 

L(y) = V {n) +ai(x)y {n ~ l) + . . .+a n {x)y = b{y), (6) 

where under suitable conditions solutions always ex- 
ist, though they may not have a simple closed form 
representation. 

In the case when all the are constant the so- 
lutions to L(y) = 0 are found by computing the 
eigenvalues, or roots of the characteristic equation 

A" + on A" 1 + . . . + a n = 0. (7) 

Thus for example when n = 2 the equation 

L ( y ) = y” + 2 by' + cy = 0 (8) 

has general solution given by 
(j>(x) = 

exp (—bx)(A + Bx), 7 = 0 
exp(— bx)(Aexp(i/jx) + B exp(— ^/jx)), j > 0 
exp(— bx)(Acos(x^— j) + Bsin(xy / —j)), j < 0 

(9) 



where 7 = b 2 — c. This description of the solution 
may be further refined to include its qualitative be- 
havior: for example in case 7 = 0, the system oscil- 
lates, and if b > 0 it tends to zero (is damped), if 
b < 0, it tends to infinity and if b = 0 it is stable. 

Current mathematical research emphasizes dy- 
namical systems, that is, roughly speaking, solution 
spaces of systems of differential equations like PP1. 
Linear systems in n variables can be expressed as a 
vector equation X' = AX, where A is an n x n ma- 
trix, and the solutions are given in terms of eigen- 
values of A. This again allows us to predict the 
limiting behavior of such a system, and to identify 
fixed points (equilibrium points) where X' = 0 , and 
behavior near to them: for example does a point 
near the equilibrium point move towards it (a sink) 
or away from it (a source). In two dimensions an 
analysis like (9), called a phase plane analysis, is 
possible: in dimensions above two chaotic phenom- 
ena can occur. 

For non-linear systems like the predator-prey 
model there are extensive theories of existence and 
uniqueness of solutions. An important practical 
technique for investigating qualitative behavior near 
a fixed point is that of taking a linear approxima- 
tion there and using this to do a phase plane analy- 
sis. The full mathematical analysis of such behavior, 
and of the underlying dynamical systems, possible 
chaotic behavior and so forth, requires the full ap- 
paratus of modern differential geometry. 

Applications 

In the initial stages the modeler may want to ma- 
nipulate and transform the model and get a few 
rough assessments of its behavior. The next stage 
would be a more detailed investigation, to compare 
it with alternatives, to calibrate it against data, 
theory or other models, and to assess its perfor- 
mance. At a more mature stage models may be used 
for prediction or for reference points against other 
models, as components in larger systems, or refined 
as new data or theoretical understanding becomes 
available. 

For example Hammersley’s [12] maxims for ma- 
nipulators at an early stage include: “clean up the 
notation, choose suitable units, reduce the number 
of variables, and avoid rigor like the plague as it 
only leads to rigour mortis”, to which one would 
probably add today “visualize the solution” . 

A typical more detailed investigation might in- 
clude: 

• solving a system of differential equations sub- 


ject to initial values or boundary conditions: ei- 
ther analytically or numerically 

• reachability analysis: determining if there is an 
analytic or numeric solution satisfying a set of 
constraints, typically that it starts in one region 
and passes through another. Thus in example 
(2) the point (7r/2, 2) is reachable from (0,1), 
but (r, 3) is unreachable for any value of r 

• identification of behavior near a stationary 
point: for example by a phase plane analysis 

• limiting behavior over time: for example by an 
eigenvalue analysis generalizing (9) 

• perturbation analysis: to identify behaviors of 
the model under local variations 

• behavior as some parameter varies: for example 
changes in the phase plane as a coefficient varies 

Taking a formal methods perspective one might 
expect to see more general reasoning about prop- 
erties of the solution, for example using temporal 
logic. Recent work in the hybrid systems commu- 
nity addresses this for control systems using tools 
such as HyTech [17], and Dutertre [7] gives exam- 
ples of reasoning about upper bounds in the require- 
ments of an avionics application, but such work does 
not seem to be considered at all mainstream in the 
modeling community. For example searches in Cite- 
seer [3] turn up little of relevance. 

Correctness issues 

In analyzing correctness issues for modeling we first 
turn to the correctness of the underlying mathemat- 
ics. 

We note first that applications of modeling are 
not in practice a particularly rich source of novel 
mathematics. There is in general [28] little en- 
thusiasm for spending a long time developing new 
equations for a particular modeling problem. Stan- 
dard techniques, like linearisation or power-series 
approximation, for replacing one equation with an- 
other that behaves in roughly the same way, may 
be sufficient when experimenting with a number of 
models at an early stage. The community tends to 
work with a smaller number of systems which are 
reasonably well understood or mathematically well- 
behaved and which experience or consensus deems 
sufficient for the domain at hand. 

The researcher in dynamical systems, the applied 
mathematician or numerical analyst ‘toolsmith’ and 



the modeler applying those techniques are doing dif- 
ferent things. The researcher is concerned with gen- 
eral theories about the existence of solutions or the 
behavior of families of systems. The toolsmith is 
developing effective techniques for solving problems 
like those above, with the researcher’s work to as- 
sure correctness. Modelers usually want to take the 
underlying mathematics for granted, concentrating 
instead on the modeling issues that arise: their 
mathematical interest or understanding is perhaps 
unlikely to go beyond a work-a-day account at the 
level of [28]. In particular the researcher is doing 
proofs in the underlying theories, the toolsmith is 
doing proofs about hand or machine computation 
techniques, and the modeler is applying those com- 
putation techniques. 

We have discussed at length elsewhere [25] atti- 
tudes to correctness in the mathematical commu- 
nity: we identified current mathematical practice 
with producing conjectural mathematical knowl- 
edge by means of speculation, heuristic arguments, 
examples and experiments, which may then be con- 
firmed as theorems by producing proofs in accor- 
dance with a community standard of rigour, which 
may be read by the community in a variety of ways. 
Most of the mathematics used in applications of 
modeling is not particularly novel, and has been 
subject to the usual mechanisms of community in- 
spection through courses and text books over many 
years: there does not seem to be much concern from 
the mathematician, the toolsmith or the modeler 
over its correctness. As is usual in contemporary 
mathematical culture few are much concerned with 
formal proof or matters of foundation. 

When a new technique arises, for example the 
recent growth of interest in level set methods [35], 
the focus of the discussion is generally on new ap- 
plications, or on faster or better (for example with 
less instability near cusps) performance in old ones, 
rather than on extended discussions of correctness. 

5 Computational techniques 

Numerical methods 

The standard, and almost universal, approach to 
computation for modeling, is numerical methods, 
which have been part of applied mathematics and 
the physical sciences for almost fifty years. They 
are widely available through standard commercial 
libraries such as NAG [29] and MatLab [27], and 
provide the basis for large software systems, usually 
written in FORTRAN or C and used in chemical, 


physical or astronomical research as well as in prac- 
tical fields like engineering, meteorology and aero- 
nautics and increasingly today in visualization and 
animation. Purpose-built implementations, for ex- 
ample, for biosciences, environmental modeling or 
geology are built on top of general purpose tools 
such as Simulink [36] which provides a graphical in- 
terface to MatLab. For example Simulink may eas- 
ily be used to run the predator-prey model for dif- 
ferent values of the parameters, generating numeric 
or graphical output, from which various properties 
of the system may be inferred. 

In addition such systems can readily accommo- 
date other inputs, for example from sensors or mea- 
suring devices, or other numerical procedures, such 
as curve fitting. For many problems, for example 
the investigation of chaotic phenomena, there are 
no alternative standard techniques. 

From the modelers point of view the main ad- 
vantage of numerical systems is that they will al- 
ways give an answer, and despite the negative ev- 
idence we cite below, with sufficient user expertise 
are accepted as doing so sufficiently quickly and ac- 
curately, with established protocols for testing and 
error analysis. Numerical methods and software like 
NAG or Simulink are so standard and so widely 
used that it is hard to see them being displaced by 
other techniques. However the output, and proper- 
ties derived from it, will always be numeric and not 
analytic, and support for investigating properties of 
the solution or parameters may be limited. 

Numerical methods: correctness issues 

The user of such systems can use default settings 
and work in ignorance of the underlying numerics, 
or take more detailed control using standard tech- 
niques of numerical analysis [18] to ensure results 
of required accuracy. Indeed, faster and more ac- 
curate numerical methods have been the main re- 
search thrust in numerical analysis over the past 
forty years. 

A particular issue in numerical work is correct- 
ness of floating point implementation (for example 
the famous Pentium bug): the consistent handling 
of floating point arithmetic or the translation be- 
tween machines with different word-lengths are re- 
curring legacy issues. Another is convergence crite- 
ria: is the implementation robust enough to produce 
the same answer again for the same inputs. Kahan 
[21] maintains a web-site of known problems. 

Yet problems persist and even expert users may 
be unaware of them. The author was told of a 



complex bug in the British Met office implemen- 
tation of the multi-grid finite element method that 
was worth about 2% accuracy in weather forecasts. 
Hatton [15] reports on observations of nine indepen- 
dently developed large programs for seismic data 
processing, and shows that although the programs 
used the same data and were developed to the same 
specifications in the same language (FORTRAN), 
numerical disagreement grows at a rate of 1% in 
average absolute difference per 4000 lines of imple- 
mented code. The programs were used to analyze 
large scientific datasets where typically results ex- 
pect around 0.001% accuracy. He concluded that 
in general problems were caused not by compiler or 
hardware errors, but by software faults, often off- 
by-one errors. However the matter has not received 
much recognition in the modeling community [16]. 

Symbolic computation 

Symbolic computation techniques, such as those 
embodied in Maple or Mathematica, appear to offer 
a wide range of additional facilities to the modeler, 
especially when combined with numerical methods. 
Thus the dsolve command in Maple, or the DSolve 
command in Mathematica, can solve a wide variety 
of differential equations analytically, and the user 
can further interact with the system or write their 
own code, to investigate their properties. As the ac- 
count of the mathematics above demonstrates, im- 
plementations rely on other symbolic computation 
techniques, such as integration, polynomial solving 
and computing eigenvalues and eigenvectors. 

There is continuing lively debate over the respec- 
tive merits of symbolic and numeric computation, 
and active research on the best way to combine 
the two approaches. The main drawback from the 
user’s point of view is that computer algebra sys- 
tems are simply unable to solve many of the prob- 
lems listed above, either because of unsolvability or 
intractability. Even if there are symbolic solution 
techniques such systems do not scale, and there are 
not in general well-developed techniques for combin- 
ing numeric input or techniques with symbolic ones: 
hence they lack the flexibility of numerical systems. 

Thus for example while symbolic techniques for 
reachability analysis using quantifier elimination 
have been investigated [20], they are in general dou- 
ble exponential, and intractable in all but the small- 
est examples. 

There are a few cases where symbolic techniques 
are better developed than numeric ones, for example 
the use of model checking in systems like Hytech to 


reason about hybrid systems, discrete combinations 
of control systems. There are also a few applications 
where symbolic systems are used in preference to 
numerical systems, for example in robotic or satel- 
lite motion planning. 

Symbolic computation: correctness issues 

By contrast with numerical techniques, users often 
find symbolic computation or computer algebra sys- 
tems (CAS) like Maple frustrating and hard to use: 
see Wester [37] for a survey. Even in situations 
where the user is expecting them to work they may 
fail to produce an “obvious” answer, or produce un- 
expected or wrong answers, and their performance 
can be very unpredictable, varying widely on appar- 
ently similar inputs. 

One cause of error is failure to check side- 
conditions: this is not so much an error as a de- 
sign decision for ease of use, since even small proce- 
dures may produce large numbers of side conditions, 
often intractable or undecidable. This illustrates 
a more general design issue: there are many ex- 
amples of processes (for example definite symbolic 
integration via the Fundamental Theorem of Cal- 
culus) where a CAS may be able to compute an 
answer, sometimes correct, on a large class of in- 
puts, be provably sound on only a subclass of those 
inputs (where the function is continuous) and be 
able to check soundness easily on a smaller subclass 
still (for example, since continuity is undecidable, 
systems use a simpler check for functions with no 
potential poles or discontinuities). Some CAS are 
cautious, only giving an answer when pre-conditions 
are satisfied: however this means they may fail on 
quite simple queries. Others try and propagate the 
side conditions to inform the user, though this can 
rapidly lead to voluminous output. Mathematica 
and Maple generally attempt to return an answer 
whenever they can and leave to the user the burden 
of checking correctness. In [1] we have analyzed this 
in some detail for symbolic integration, and pro- 
posed a solution based on verified look-up tables. 
We extended our ideas to dynamical systems and 
mathematical modeling in [26], with a suite of PVS 
tools to check definedness and continuity, callable 
from Maple. 

However there is a deeper reason for appar- 
ent unsoundness than failure to check for side- 
conditions. Formally CAS compute indefinite in- 
tegrals and solve differential equations within the 
algebraic framework of the theory of differential 
fields [2]: fields with an operator satisfying d(f.g) = 



(df).g + f.(dg). When using an indefinite integral as 
part of an analytic calculation, for example solving 
a differential equation, the answers obtained alge- 
braically may differ significantly from what is ex- 
pected. For example, viewed as an element of a dif- 
ferential field, the derivative of f(x) = tan -1 (a;) + 
tan -1 (1/a;) is zero, and it follows that f(x) is a 
constant. Viewed analytically it is a step function 
with the value — 7 t/ 2 for x < 0 and 7 t/ 2 for x > 0. 
Thus an “unexpected” answer to a query involving 
f(x) may be correct within the theory of differential 
fields, but incorrect in the usual analytic framework 
for differential equations we have presented above. 
Similarly it is easy to get Maple’s dsolve command 
to display behavior which is unsound analytically, 
as it applies (4) without checking continuity of a 
and b. 

This analysis should be kept in perspective how- 
ever: developers of the symbolic software systems 
GAP [34], axiom[19] and Aldor [19] indicate that 
the majority of bug reports tend to uncover user 
misunderstanding, performance, or systems flaws, 
especially to do with portability, rather than prob- 
lems with the underlying mathematics or algo- 
rithms. For example of approximately 1100 bug re- 
ports on Aldor only one reported a problem with an 
incorrect library implementation, involving a failure 
to detect a division by zero. 

6 Correctness concerns for modeling 

We now return to correctness concerns for 
the modeling process, and consider the pipeline, 
{reality- purposes} -¥ model world — ¥ model -¥ im- 
plementation. 

One may first ask whether the “implementa- 
tion” is a correct implementation of the underlying 
“model”. In particular we may ask which aspects 
of its behavior are artifacts of the “implementa- 
tion” (for example a poor choice of random number 
generator) rather than consequences of the model, 
or what hidden or explicit assumptions about the 
model have been made and how they affect the uses 
to which the system has been put. For example, if 
the system is used in a new application and predicts 
that x > 3, is this a consequence of the model, or 
of some implementation decision being called upon 
outside its domain of validity. 

Heterogeneous distributed implementations of- 
ten incorporate large legacy systems where the un- 
derlying assumptions may have varied over time, 
where later implementors may not have fully un- 
derstood the original assumptions, or have incorpo- 


rated variations based on new results, or where the 
underlying models may be incompatible. Thus for 
example an implementor may have hard-wired an 
implicit assumption about, say, the life span of a 
predator which is totally inaccessible to later users, 
and may lead to nonsensical results when combined 
with a different implementation. 

The correctness of an implementation concerns 
how the “implementation” of a model matches the 
“model”: of much greater concern in the model- 
ing community is the assessment of the “model” 
against its “purposes” , or against other models with 
the same or related purposes. In such discussions 
the “model” and its “implementation” may often 
be identified, particularly if we only have numerical 
information about the model. An excellent account 
from the point of view of environmental predictions 
is given in Oreskes [31]. 

The correctness of a “model” is in any case con- 
tingent: it says that under the hypotheses of the 
“model world” certain consequences occur, and the 
output of the implementation may be regarded as 
a prediction, with estimates of error being provided 
by mathematical analysis in the light of the model 
and the reliability of the data. The hypotheses of 
the model world may not necessarily be very clear 
or explicit, being part of the assumed background 
knowledge of domain experts. Care needs to be 
taken with data: for example a famous data-set on 
Canadian hare and lynx populations was discredited 
[11] when it was pointed out that the lynx and hares 
lived far apart and had little opportunity to eat each 
other. Our ability to test the correspondence of 
the “model world” with the “real world” depends in 
part on our understanding of the phenomena, and in 
part on the availability of sufficiently accurate data. 
So questions of correctness of a particular model are 
complicated and often subject to heated debate or 
compromise. 

In some cases predictions may be easy to check: 
the occurrence of the full moon for example is read- 
ily observed and not subject to major disagreement. 
So if a model with a trustworthy implementation 
whose purpose is to predict the full moon fails to do 
so we may reasonably assume the “model”, or the 
“model world” is incorrect. Even then it may not be 
at all clear which assumption or equation has led to 
the error. However most models cannot be checked 
in so straightforward a way: for example the aver- 
age temperature of the earth needed in models of 
global warming is hard to measure or estimate, and 
in other cases it may be infeasible to check the pre- 
dictions: for example safety thresholds for aircraft 



loads or discharge of pollutants. 

Models may be known by insiders to be in- 
accurate, but none-the-less used as a best guess, 
or treated as accurate even though they are not. 
Mackenzie [24] reports on the debate surrounding 
the abandonment of nuclear weapons testing, draw- 
ing attention to the importance of tacit knowledge 
in the practical development of nuclear weapons, 
and the possibility that they might be “uninvented” 
if this tacit knowledge is lost. He reports scientists’ 
claims that a computer prediction is “pretty good” 
if the actual yield is within 25% of prediction, and 
notes that during the moratorium on nuclear testing- 
in the 1950s dependence on and confidence in com- 
puter programs increased: according to an intervie- 
wee “people start to believe the codes are actually 
true, to lose touch with reality.”. 

Experts may disagree as to the acceptability of 
the model: Shrader-Frechette [39] reports disagree- 
ment among two expert committees in the 1993 as- 
sessment of the proposed Yucca Mountain Waste 
repository site as to whether the large and well- 
established geological models used could reliably 
predict volcanic activity. We may have several com- 
peting models: for example Gilpin and Alaya [9] 
used experiments on competing populations of fruit- 
flies to test different variants of the predator-prey 
“model” and “model world” against the purpose of 
accurate prediction of fruit-fly populations. They 
compared their models against the accuracy of their 
results, favoring those where the model world made 
most sense biologically, and those where the model 
was simple and general 3 . However it may not be 
the case that we can always chose among compet- 
ing models so readily. 

Matters become more complex when we con- 
sider many-layered models, where for example test- 
ing against “the real world” may mean in practice 
testing against another “implementation” of a dif- 
ferent “model” that has acquired the standing of 
“the real world” for practical purposes. In assessing 
model PP2 for example we would need numbers of 
hares and lynx: would we do every count by hand 
or use “implementations” of established “models” 
of wild-life numbers calibrated with key data from 
field studies. And how might the assumptions of 
the latter affect the predictions of PP2? 

As we have indicated a particular concern is the 
combining of different models or implementations. 

3 A much argued philosophical point. It has been sug- 
gested [31] that the quest for simplicity and generality, identi- 
fied with Ockham’s Razor, owes more to seventeenth century 
theology and mathematical convenience than any evidence 
that simple models are better predictors than complex ones. 


Different models may address different parts of our 
purposes differently, or in choosing to model part of 
a larger scheme we may have to choose between sev- 
eral models none of which are entirely satisfactory. 
Assumptions may be incompatible or unclear: this 
is a particular issue for legacy components where as- 
sumptions may be concealed, contradictory, or have 
changed over time. 

7 How can formal methods con- 
tribute? 

Putting together the ingredients described above 
we may identify the business of modeling with 
first developing generic mathematical theories, al- 
gorithms, and implementations, both numeric and 
symbolic, and then modeling particular systems by 
implementing them within the chosen framework as 
part of the modeling pipeline. Correctness concerns 
may be raised at all levels of the process: the math- 
ematics, the software systems, the implementations 
of the model and the correspondence of the model 
with reality. As far as we can tell this last is of most 
concern to the modeling community. 

Formal methods, broadly construed, offers a va- 
riety of approaches. 

Mathematical theories 

Since the pioneering work of de Bruijn’s AU- 
TOMATH [4], developed in 1967, the theories of 
analysis which underlie differential equations and 
mathematical modeling have been developed inside 
various theorem provers: for recent manifestations 
see Dutertre’s implementation of the reals inside 
PVS [7] or Harrison’s development as far as inte- 
gration in HOL [14]. As far as we are aware a full 
machine verification of the mathematics outlined in 
the previous sections has not yet been done, but it 
is perfectly feasible in a number of systems, using 
classical or constructive techniques. However while 
this is possible, it is hard to see how it would serve 
the needs of the modeling community, who regard 
the soundness of the underlying math as a “solved 
problem” , established over many years in text-books 
and courses. They rely on mathematicians, and 
the usual community mechanisms of mathematics, 
which are remarkably averse to rigour [25], to es- 
tablish correctness of the necessary mathematics: I 
have identified little interest in human or machine 
formal proof for the classical mathematics under- 
lying the subject, the work of the toolsmith, or its 
routine application in modeling. This is not to write 



off machine checked mathematics as an endeavor, 
merely to say that this community sees little point 
to it. While logicians [8] have considered alterna- 
tive axiomatizations for differential analysis I have 
identified no interest among the mainstream math- 
ematical or modeling community in these matters. 

Once such a development had been done it would, 
in principle, be possible to investigate our mod- 
els directly within the prover, recasting the various 
queries outlined in Section 4 as proof requirements, 
for example the reachability results of example (2). 
However it is hard to see how such systems would 
overcome the difficulties we have already discussed 
for symbolic computation systems: infeasibility or 
intractibility mean that often there will not be an 
automatic proof procedure, and users will need to 
produce a manual proof of something whose numer- 
ical equivalent could be produced automatically. In 
addition any such system would need a computa- 
tional component if it was to match the exploratory 
capacity of existing techniques, and as Section 4 
shows many of the computations or proofs would re- 
quire advanced symbolic computation facilities, for 
example to calculate eigenvalues. 

Against this however we should set the advan- 
tages of abstraction, higher level proof and the han- 
dling of parameters: for example it takes laborious 
numerical simulation to investigate changes in the 
phase plane as a coefficient varies, whereas a sym- 
bolic approach merely produces a proof obligation 
to be discharged. 

In addition, as we have argued elsewhere [25] spe- 
cialized decision procedures may prove useful for 
some queries, for example quantifier elimination for 
reachability [20]. 

Computational techniques 

As we have seen general software engineering issues 
have been identified as a major source of problems in 
both numerical and symbolic software: since these 
problems and formal methods approaches to them 
are not peculiar to modeling we do not discuss them 
further here. The modeling community relies on the 
usual mechanisms of software development, which 
are averse to rigour, to establish trustworthiness of 
its computer systems: I have identified little inter- 
est among commercial vendors in classical formal 
methods techniques. 

It is in principle possible to implement numerical 
or symbolic computation inside a theorem prover, 
gaining reliability at a cost in performance, and 
both approaches have received much attention in 


recent years. The notorious “Pentium bug” drew 
attention to the unreliability of floating point imple- 
mentations, and inspired Harrison’s development of 
floating point arithmetic in HOL [13] which has had 
considerable commercial impact in the verification 
of hardware. 

Such implementations of computer algebra sys- 
tems have proved harder, partly because, as we 
have indicated, they require implementation inside 
a prover of specialized algorithms such as factoriza- 
tion. In any case, some of the unexpected behaviors 
of computer algebra systems arise from the alge- 
braic representation of analysis: these would not be 
solved by re-implementation inside a prover. We re- 
port elsewhere [26] on an alternative approach: we 
built a toolkit in the PVS [32] theorem prover which 
automatically checks pre and side conditions such 
as continuity to computer algebra algorithms such 
as Maple’s dsolve, thus addressing some of the dif- 
ficulties caused by unsoundness in using computer 
algebra systems for analytic work at little extra cost 
to the user. 

Modeling 

As we have indicated the main concerns of the mod- 
eling community are with the correctness, validation 
and confirmation of models. 

We report elsewhere [5, 6] on our lightweight 
formal methods approach: we built a verification 
condition generator in Aldor, an internal language 
used in developing the computer algebra systems 
axiom and Maple, and are currently developing this 
work in collaboration with NAG Ltd. The verifica- 
tion conditions are generated at compile time from 
user annotations, typically recording pre- and post- 
conditions, and can be passed to a theorem prover 
or used for information or documentation. 

Our original motivation was particularly that of 
assisting the user of libraries where the code it- 
self might be trusted, but the assumptions or pre- 
conditions for its correct use were ill-documented. 
We are currently experimenting with the use of 
these annotations for documenting requirements 
and assumptions in legacy models. 

However there appear to be some differences be- 
tween the needs here and those of design or require- 
ments engineering: in particular there are cases 
where it seems useful to record assumptions or do- 
main knowledge that does not affect the state or 
output of the module where it is recorded or as- 
sumed, but may be significant elsewhere. It is 
not entirely obvious to us how to map the mod- 



eling pipeline to frameworks such as the reference 
model of Gunter et al [10], which is based on do- 
main knowledge, requirements, specifications, pro- 
gram and program platform. 

We note that these matters are beginning to 
receive commercial attention: Lemma 1 Ltd [23] 
report on their ClawZ system which translates 
Simulink diagrams into Z specifications, and the UK 
company QSS [33] have interfaced their DOORS re- 
quirements tool to Simulink. 

8 Some new directions 

The previous section paints a somewhat depress- 
ing picture, suggesting that many areas which have 
received considerable research attention are unlikely 
to have much effect on the practice of modeling. We 
might sum up by observing that the modeling com- 
munity are users rather than creators of mathemat- 
ics and software, and by and large take both the 
mathematical theories underlying their work and 
the largely commercial computer systems that im- 
plement them pretty much for granted as “solved 
problems”. The main concerns lie elsewhere and 
there is little interest in or motivation for change, 
and a heavy personal and financial investment in 
existing technologies. 

We can none-the-less outline some ways ahead. 
The modeling community, like many others, are in- 
terested in new methods that fit their present world 
view, address their main concerns or improve or ex- 
tend existing techniques or software. 

The correctness, validation and confirmation 
of models is of primary importance to the mod- 
eling community, and of particular concern when 
these impact public policy in matters such as nu- 
clear waste disposal. It is the assumptions, data 
and choice of model that seem to matter here, not 
questions about correctness of the underlying math- 
ematics or software once the model has been cho- 
sen. We are not even aware of a suitable framework 
for the analysis of requirements, specifications, as- 
sumptions and proof obligations for modeling within 
our pipeline: an extension of the reference model of 
Gunter et al [10] may be appropriate. Computa- 
tional logic has a useful role to play in monitoring 
and analysis here, and hence in reasoning directly 
about the assumptions of the “model world”, the 
“model” and the “implementation” . 
Heterogeneous distributed models are of par- 
ticular current interest, put together for example 
across the Internet, with disparate or legacy com- 
ponents where assumptions may be concealed, con- 


tradictory, or have changed over time. An engine for 
managing requirements and assumptions would be 
a key component technology of robust architectures 
for linking such heterogeneous models. Particular 
care would need to be taken over the layering issues 
indicated above. Projects such as Open Math [30], 
which attempt to provide reliable interface mecha- 
nisms for heterogeneous mathematical systems us- 
ing type inference seem relevant here also. 

New analytic, numerical or visualization 
techniques which leverage off the established 
mathematical and computational framework and 
extend its functionality are of interest. For exam- 
ple, as we have seen, computer algebra systems are 
useful in the analytic study of dynamical systems, 
especially those with parameters, but these are error 
prone: extending them using computational logic 
engines as we have indicated above adds function- 
ality at little cost to the user. 

Symbolic analysis Numerical analysis software 
does continuous mathematics numerically, com- 
puter algebra software does continuous mathemat- 
ics symbolically by algebraic means, but no software 
yet does continuous mathematics symbolically by 
analytic means, and it is not clear how it should be 
done. As we have indicated this is the underlying 
reason for the deficiencies of computer algebra sys- 
tems: solving it would indeed make possible a new 
generation of useful computational tools. It is not 
enough to formalize existing computer algebra sys- 
tems based on differential rings: these will not give 
us true computational analysis. It is not enough to 
prove theorems about real analysis inside a theorem 
prover: we need to be able to do computations like 
those described in Section 3 as well. 

We urge the formal methods and computational 
logic community to take up these challenges. 
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Abstract: The safety of modern avionics 
relies on high integrity software that can be 
verified to meet hard real-time requirements. The 
limits of verification technology therefore 
determine acceptable engineering practice. To 
simplify verification problems, safety-critical 
systems are commonly implemented under the 
severe constraints of a cyclic executive, which 
make design an expensive trial-and-error process 
highly intolerant of change. Important advances 
in analysis techniques, such as rate monotonic 
analysis (RMA), have provided a theoretical and 
practical basis for easing these onerous 
restrictions. But RMA and its kindred have two 
limitations: they apply only to verifying the 
requirement of schedulability (that tasks meet 
their deadlines) and they cannot be applied to 
many common programming paradigms. 

We address both these limitations by 
applying model checking, a technique with 
successful industrial applications in hardware 
design. Model checking algorithms analyze finite 
state machines, either by explicit state 
enumeration or by symbolic manipulation. Since 
quantitative timing properties involve a 
potentially unbounded state variable (a clock), 
our first problem is to construct a finite 
approximation that is conservative for the 
properties being analyzed — if the approximation 
satisfies the properties of interest, so does the 
infinite model. To reduce the potential for state 
space explosion we must further optimize this 
finite model. Experiments with some simple 
optimizations have yielded a hundred-fold 
efficiency improvement over published 
techniques. 

1 The safety of hard real-time 
software 

Modern avionics relies fundamentally on 


high integrity software that meets hard real-time 
requirements such as schedulability — the 

guaranty that all tasks meet their deadlines. It is 
common to implement a high integrity real-time 
system by means of a cyclic executive, in which 
programmers explicitly allocate the execution of 
processes or process fragments to portions of a 
master control loop. This technique has the 
strengths of requiring essentially no runtime 
support and of making schedulability analysis 
ttivial. But the design of a cyclic executive is 
expensive and time-consuming, relies heavily on 
nial-and-error rather than systematic design 
principles, and is highly intolerant of change. 
Small modifications to individual processes may 
require complete redesign of the master control 
loop, hi addition, this narrowing of the design 
space potentially constrains the introduction of 
automation technologies that could improve both 
safety and performance. 

The alternative to a cyclic executive is some 
form of preemptive scheduling hi which 
processes are scheduled dynamically. Preemptive 
scheduling immediately presents two problems: 
First, static analysis of program behavior 
becomes much more difficult. Second, the 
runtime support required to cany out dynamic 
scheduling must be efficient and must admit an 
implementation simple enough to satisfy the 
certification requirements for high integrity 
systems. Raven [32] is an example of such a 
runtime. 

The best-known analysis technique for 
preemptive scheduling is Rate Monotonic 
Analysis (RMA) [19], which applies to a 
restricted but useful class of systems and reduces 
schedulability analysis to checking a set of 
simple algebraic inequalities. However, RMA 
does not provide information about properties 
other than schedulability and is not applicable to 
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many common programming paradigms: Figure 
1 provides an example of such a program. Nor 
does RMA cover properties other than 
schedulability. 

This paper describes art ongoing investigation 
of model checking as a supplement to RMA. 
Model checking comprises automated techniques 
that apply, in principle, to arty system 
representable as a finite state machine. These 
techniques are of two general lands: explicit 
search (clever strategies for visiting all possible 
states) and symbolic model checking (combining 
symbolic execution and automated reasoning). 
Both styles can be used to analyze properties 
other than schedulability and systems that do trot 
meet the design restrictions imposed by RMA. 
Our work shows that model checking can be 
applied to some systems beyond the reach of 
current analytical techniques. The technical 
barrier to making these applications practical and 
routine is die possibility of state space explosion. 
We are investigating optimization techniques 
tiiat generate efficient representations of the 
system to be analyzed. 

1. 1 Ravenscar and Raven 

Tire general principles we employ ar e not tied 
to any particular implementation, though the 
details will necessarily depend on the 
programming language and runtime system 
being modeled. Tire Ravenscar Profile [8] 
defines a set of Ada tasking features rich enough 
to support (among other things) rate monotonic 
scheduling, but requiring a minimal runtime. 
Ravenscar is supported by the Raven runtime, 
developed at Aonix to meet the highest FAA 
certification standards for safety critical systems. 
The tasking subset we consider can be regarded 
as a generalization of Ravenscar, together with a 
technical requirement, which we call frame 
synchronization, that reduces nondeterminism by 
eliminating arbitrary task phasings. Thus, the 
analysis we propose can be directly applied to 
real systems. 

1 . The mam features of the Ravenscar 
subset are as follows: 

2. The number of tasks, and the base 
priority of each, is fixed and statically 
determined. 

3. Scheduling is preemptive, using the 
priority ceiling protocol. 

4. Tasks interact only through protected 
objects. No more than one task may ever 


be queued on the entry of any protected 
call. (This limit on the size of the entry 
queues is a dynamic requirement that 
cannot in general be enforced by 
syntactic restrictions.) 

5. Task behavior is deterministic. 

Figure 1, based on an example from [16], 
illustrates a simple Ravenscar program to which 
RMA does not apply. Three sensors periodically 
sample flight data and send it via a bounded 
buffer to an analyzer that periodically reads die 
data from die buffer. The buffer is implemented 
as a protected object containing a protected entry 
for writing data and a protected procedure for 
reading it. A read from an empty buffer returns 
some conventional value. The buffer’s write 
entry blocks the sensors from writing when die 
buffer is full. The protected read procedure 
blocks the analyzer from reading while die buffer 
is being written to. (We make die read operation 
a procedure radier dian an entry because 
Ravenscar forbids protected objects with more 
dian one entry. That is why read does not block 
on any empty buffer, but reads some 
conventional value.) RMA does not apply 
because each of die periodic sensor tasks 
contains a protected entry call, at which it can be 
blocked. 

1.2 Model-checking real-time 
properties 

Many existing models for real-time systems 
are based on tuned automata [2] or, more 
generally, hybrid automata [1]. These models 
contain state variables that represent the values 
of real-tune clocks. Notice diat a direct model of 
time, by means of a variable containing die 
current value of the clock, leads to an infinite 
state space, since die clock may increase widiout 
bound. Some form of temporal abstraction is 
required. The abstraction used to analyze hybrid 
automata is to represent regions — sets of 
states — symbolically, via logical formulas. 
Symbolic manipulation of such formulas [20] is 
the heart of model checking tools such as [4]. 

hi [10], Corbett presents a two-stage 
construction that models real-time Ada tasking 
programs (together with the supporting runtime) 
as hybrid automata. The first stage translates a 
program to a transition system representing the 
possible interleavings of the tasks’ execution. 
The second stage captures die timing constraints 
of the program by transforming the transition 




Figure 1: A Ravenscar example to which RMA does not apply 


system into a hybrid automaton. This hybrid 
automaton is then analyzed by the HyTech 
verifier [11], which can be regarded as symbolic 
model checker. 

hi [16], we developed a method for 
constructing models of real-time tasking 
programs in Promela [12], a language for 
specifying communicating sequential processes. 
The program’s tasks and the runtime system are 
represented as Promela processes. The frame 
synchronization requirement mentioned above 
allows us to eliminate the real-time clocks from 
die system’s model altogether and thereby to 
represent the system as a simple transition 
system rather than a hybrid automaton. We 
introduce state variables to keep track of upper 
and lower bounds on the completion time of each 
process, and perform a “dynamic abstraction” of 
these time-related state variables to make the 
state space finite, hi essence, the pah of 
completion times for each process defines the 
region of states in which the process is running. 
This representation is much simpler than 
representation by a logical formula. We then 
analyzed the Promela program with the Spin 
verifier [12], 

Many other formal models have been 
proposed for concurrent real-time systems [3]. 
These include Petri nets [14], tuned automata 
[2], tuned process algebras [17], and real-tune 
logics [13], For the most part, these models are 
intended to represent specification, not 
implementation, hi [5], general tuned automata 
are extended to represent such implementation 
details as the assignment of tasks to processors, 
priorities, worst-case execution times of 
operations, and scheduling policies. Our model 
compares to [5] much as it does to [10], 


2 A simple illustration 

This section uses a trivial example to show 
how the “dynamic time abstraction” of [16] can 
be combined with reduction techniques from 
[10] and illustrate its effectiveness. Although 
there are enough differences that a quantitative 
comparison is not strictly scientific, we obtain a 
hundred-fold advantage over [10] in both speed 
and memory usage and a ten-fold advantage over 
[16]. 

2.1 A schedulability problem 

Consider two periodic, non-interacting tasks, 
A and B, run on a single processor under 
preemptive scheduling. Task A has higher 
priority than B. Although this trivial tasking 
pattern can be analyzed by RMA. it allows us to 
illustrate essential features of our proposed 
strategy and to perform a simple comparison 
with Corbett’s analysis via a hybrid automaton 
model. 

A code skeleton is given in Figure 2. We 
assume that the variable StartTime records the 
value of the system clock at some moment after 
the tasks have been initialized but before they 
start running, hi effect, this implements the 
frame synchronization assumption. StartTime 
can be initialized to satisfy the assumption by 
using a simple Ada coding idiom given in [16], 
The code fragments <statementsl> and 
<statements2> implement periodic activities 
whose functionality is irrelevant to the tasks’ 
timing. Let estimA and estimB be upper bounds 
on the amount of CPLT time necessary to execute 
the bodies of the loops in task A and task B 
respectively. We assume that CPLT time is the 
tasks’ only shared resource. The parameters 








task A is 

task B is 

pragma Priority (20); 

pragma Priority (10); 

end A; 

end B; 

task body A is 

task body B is 

nextA: Time = StartTime; 

nextB: Time = StartTime; 

begin 

begin 

loop 

loop 

<statements1> 

<statements2> 

nextA := nextA + periodA, 

nextB := nextB + periodB', 

delay until nextA; 

delay until nextB; 

end loop; 

end loop; 

end A; 

end B; 


Figure 2 : A two-task problem 


and periodA and periodB define the periods of 
task A and task B. Execution of “delay until t” 
blocks a task until the system clock has value t. 
If task A reaches its “delay until next A” 
statement when the clock time is greater than 
nextA, then task A has missed a deadline. We can 
characterize a missed deadline for task B 
similarly. 

With this definition of deadline, we analyze 
the schedulability of tasks A and B in terms of 
the task periods periodA and periodB, and tire 
CPU time estimates e stint A and estimB. As 
noted, RMA handles the problem easily, but the 
point of the example is to exhibit simple 
optimization strategies that can dramatically 
improve the efficiency of analysis by model 
checking. 

2.2 A discrete model 

hi the program of Figure 2, the only variables 
affecting the timing behavior of the program are 
nextA and nextB. They are the only data variables 
represented in our model. 

To model the program’s control state, we 
completely abstract from the code fragments 
within the task loops. We represent the 
fragments as abstract actions whose executions 
take time, and whose executions can be 
preempted by higher priority actions. We model 
execution of tasks A and B as periodic 
invocations of these abstract actions. 

hi [16] we represented the runtime and each 
task as a separate process. As observed in [10], 
this simple-minded representation introduces 
unnecessary states because the actions of the 


runtime are so tightly coupled to the actions of 
die tasks. That is, we know a strong invariant 
tiiat permits a more efficient abstraction of die 
state space. Because task A has higher priority 
dian task B, we can partition die system states as 
follows: task A can be eidier running or blocked 
by its “delay until” statement; task B can be 
running, or blocked by its “delay until” 
statement, or preempted by task A; and the 
system as a whole enters an error state if either 
task misses a deadline. Thus, we represent die 
status of the program by introducing a variable 
runtime status that can have the following 
symbolic values: runningA preempted!!, 

blockedA runningB, blockedA blockedB, 

runningA blockedB , and missed deadline. 

We also introduce several valuables to model 
timing information: 

1. The integer variables lb and ub specify 
lower and upper bounds for die clock 
time at which the currently executing 
abstract action will (if not preempted) 
complete. The values of these time 
bounds vary dynamically, according to 
the program’s control flow. 

2. The integer variable delta contains an 
upper bound for the CPU time needed to 
complete the currently executing abstract 
action. When a preempted action 
resumes its execution the value of delta 
will typically be revised to reflect die 
progress made before preemption. 

3. The integer variable preernptB, called the 
preemption bound, stores the value of 
delta when task B is preempted by A. 

We specify the schedulability requirement by 




asserting that the runtime status missed deadline 
never occurs: 

Invariant "hard deadline" 

! runtime_status = missed_deadline 

The states and transitions of our model are 
shown graphically in Figure 3. We define die 
effect of each transition using die notation of die 
Murphi model-checker [33], The meaning of 

guard = = > Begin <statements> End 

is diat die transition may take place when die 
boolean guard is true; and, if it does take place, 
die effect on die state variables is defined by die 
Pascal-like code in statements. If several 
transitions may take place, then die choice of 
which transition to fire is non-deterministic. 
(Even if die Ada code is deterministic our model 
may be a conservative, non-deterministic, 
approximation.) The simple model shown here 
does not represent die overhead atdibutable to 
runtime actions such as preempting a task or 
restoring die state of a preempted task. Those 
costs are accounted for explicitly in [16]. 

Figure 4 provides definitions for duee 
representative transitions: 1, 2, and 4. Transition 
rules 1 and 2 describe the program’s behavior 
when A is running and B is preempted. Rule 4 
describes one of the possible behaviors of die 
system when task A is blocked and task B is 
running — namely, the possibility that task A may 
preempt task B. 

Rule 1: If the upper estimate of the clock 
time for completing task A is greater than or 
equal to the next deadline — that is, ub > 
nextA+periodA — then it is possible that A may 
miss its deadline; and therefore a deadline 
violation will be reported. Our model is a 
conservative approximation of the program. The 
program will satisfy any invariant satisfied by 
the model, but the converse need not be true. 

Rule 2: If ub < nextA+periodA, this iteration 
of task A will meet its deadline. Transition 2 
represents the successful completion of A, after 
which A becomes blocked until the beginning of 
its next period, and hands off to task B (as 
reflected by changing the value of 
runtime status to blockedA runningB). To do 
the necessary bookkeeping, the other state 
variables are modified as follows: 


• nextA, die next clock tune at which task 
A becomes ready to run, is incremented 
by the value of its period, 

• delta, die estimate of die remaining CPU 
time to complete task B, is restored to 
die preemption bound of B, 

• ub, which now represents an upper 
estimate of the clock time at which task 
B will complete, is increased by delta, 

• since die preemption of B has now been 
accounted for, we reset preemptB to 
zero. 

Rule 4: The guard for transition 4 represents 
die following possibility: task B will, if not 
preempted, meet its deadline; but task A becomes 
ready before die action of task B completes and 
dierefore preempts B. Among die actions of rule 
4, die interesting new feature is a call to 
procedure time wrap, which is essential for 
making our model finite. 

The state variables nextA, nextB, lb, and ub 
are regularly incremented. If we allowed them to 
increase witiiout bound our model's state space 
would be infinite. However, die presence or 
absence of a deadline violation depends only on 
die relative values of tiiese variables, not on their 
absolute values. Therefore, die relevant timing 
behavior of our model does not change if we 
recalibrate by simultaneously decreasing nextA, 
nextB, lb, and ub by the same amount. Procedure 
time wrap does the recalibration, decrementing 
all these variables by the current value of lb. Our 
transition rules will invoke timewrap 
immediately after any increment to lb. This is a 
form of rolling, dynamic time abstraction. 

This recalibration strategy will succeed in 
bounding the values of these variables if die 
differences between the values of nextA, nextB, 
lb, and ub are bounded. It is shown in [16] diat, 
for all the executions of the model in which no 
deadline is missed, the absolute values 
\nextA—lb\,\nextB -!b\, and I ub-lb\ will all be less 
than 2*max(periodA, periodB). Therefore we can 
statically restrict the range of the tune variables 
to -MAX .. MAX, where MAX=2*max(periodA, 
periodB). To be more precise, if there is a 
deadline violation in the infinite model (from 
which all occurrences of time wrap have been 
deleted), then there is a deadline violation in the 
recalibrated model, and it will be detected before 




Rule "1" 

Rule "2" 

Rule "4" 

runtime_status= 

runtime_status 

runtime status = blockedAjunningB 

runningA preemptedB 

runningA_preemptedB 

& ub < nextB + periodB 

& ub >= nextA + periodA 

& ub < nextA + periodA 

& nextA < ub 

==> 

==> 

==> 

Begin 

Begin 

nextA := nextA + periodA; 

Begin 

runtime_status := 

runtime_status := 

runtime status:=runningA_preempte 

missed deadline; 

blockedArunningB; 

dB; 

End; 

delta := preemptB; 
ub := ub + preemptB; 
preemptB := 0; 

End; 

preemptB := (ub - nextA < delta) ? 

(ub - nextA) : 

delta; 

delta := estimA; 
lb := nextA; 
ub := nextA + estimA; 
time wrap(); 

End; 


Figure 4: Representative transition rules 


execution of the model attempts an update that 
puts these variables out of range. 

2.3 A comparison 

Our experiment analyzed the example of 
section 2.1 in three ways: We applied Murphi to 
the transition system defined in section 2.2; we 


applied HyTech to the hybrid automaton 
constructed by the methods of [10] alone; we 
applied SPIN to the model constructed by the 
methods of [16] alone. The comparison with 
[10], for various values of the parameters, is 
shown in the charts below. 

We suspect that that the advantage of these 





















estimA=5, period A = 10, 

estimB = 10, periodB = 30 

Transition system 

Hybrid automaton 

Number of states! regions 

11 

8 

CPU time (sec) 

0.10 

0.24 

Memory used 

IK 

0.82M 


estimA = 29, periodA = 59, 
estimB = 61, periodB = 181 

Transition system 

Hybrid automaton 

Number of states! regions 

1002 

480 

CPU time (sec) 

0.10 

13.73 

Memoiy used 

25 K 

4.53M 


estimA = 167, periodA = 353, 
estimB = 313, periodB = 997 

Transition system 

Hybrid automaton 

Number of states! regions 

5013 

2700 

CPU time (sec) 

0.40 

106.95 

Memory used 

163K 

20.13M 


Figure 5 : A comparison 


optimizations will increase as the timing 
constraints become more complex, because 
manipulating integers is more efficient than 
manipulating linear formulas with integer 
coefficients. We cannot quantify how much of 
the difference might be attributable to the fact 
that Murphi is a more mature tool than HyTech. 

The advantage over [16] is not quite so 
dramatic — the improvement is one order of 
magnitude, not two. 

2.4 Other properties 

This section briefly considers problems other 
than schedulability. The model and the size of 
the state space depend on the property analyzed. 
For example, hi the terminology of Figure 2, it is 
easier to analyze the assertion that “Both tasks 
always meet then deadlines” than to analyze the 
assertion “Task B always meets its deadlines,” 
because uncertainty about the behavior of A 
would add nondeterminism to the model. Since 
the tasks of Figure 2 do not interact (except 


implicitly, via preemption) there is not much to 
ask about this example aside from its 
schedulability. 

When tasks do interact, things become more 
interesting. The Ravenscar rules require that no 
more than one task be waiting on the entry of 
any protected call. The main purpose of this 
requirement is to avoid the overhead of 

maintaining queues, hi general, it is undecidable 
whether a program meets the requirement, 
though compliance could be guaranteed by 
making severe static semantic restrictions on the 
code. The Raven runtime raises an error 
dynamically if execution ever violates the 

requirement. Thus, it is important to be able to 

check this rule by static analysis. A 

schedulability model of the kind suggested in 
this section already encodes enough information 
in its state to answer this question. Analysis of 
the length of entry queues is insensitive to die 
recalibration trick. 

Deadlock freedom is another interesting 









question that should be amenable to our 
techniques. The priority ceiling protocol itself 
suffices to guarantee that a certain class of 
tasking programs cannot deadlock, but the 
general question is undecidable. (This problem 
is also insensitive to recalibration.) 

2.5 Limitations 

We might hope for a divide-and-conquer 
approach whereby knowing that die system is 
schedulable — for example, in cases where RMA 
is applicable — might permit us to produce a 
simpler model widi which we might verify other 
properties. However, if die precise timing 
behavior of the program is necessary to 
guarantee diose properties, we must represent 
diat behavior in our model and dierefore encode 
die schedulability problem within it. hi effect, 
verifying schedulability is automatically part of 
verifying any property at all. Unfortunately, die 
intricacies and timing of task interleavings are 
die principal source of state space explosion. 

Our experience dius far suggests diat die 
effectiveness of our mediods will depend more 
on die underlying set of tasking primitives than 
on a discipline restricting die patterns hi which 
diey are used. Interrupts are especially 
interesting, and present special problems. In die 
model of [16] we found that code with interrupts 
typically resulted hi a state space explosion. 
Symbolic model checking may be applicable to 
this case. On the other hand, several taskhig 
constructs omitted by the Ravenscar Profile seem 
amenable to model checking analysis: absolute 
delay statement; rendezvous; select statements. 

3 More realistic examples 

This section briefly describes the application 
of our model-checking techniques to more 
realistic examples. We summarize experiments 
ushig the methods of [16] on a modest work 
station, which we have not had the opportunity 
to repeat with the optimizations proposed above. 
These examples employ the mam Ravenscar 
taskhig constructs such as “delay until” 
statements, protected procedures and entries, 
interrupts, and sporadic tasks triggered by 
interrupts. 

The modeling of interrupts and sporadic tasks 
is the most complicated part of the model of 
[16], Conceptually, a sporadic task is triggered 
by an interrupt and must complete its response 
interrupt within a specified response time. Each 


interrupt is characterized by its minimum 
interarrival time — the minimum time between 
two consecutive occurrences of the interrupt. 
The minimum interarrival time and the response 
time for each interrupt are parameters of the 
model. 

To implement sporadic tasks we use an Ada 
idiom required by the Ravenscar programming 
discipline: The response to an interrupt I is 
performed by a sporadic task T whose body is a 
loop. The head of that loop is a call on a 
protected entry E, so that task T is blocked at the 
head of the loop so long as entry barrier of E is 
false; and the last act of the loop is to reset the 
entry barrier of E to true. The text of an Ada 
program binds interrupt / to a protected 
procedure P, which will be executed by the 
runtime whenever 7 occurs; and, in this 
programming idiom, P must be implemented so 
that its only effect is to change the entry barrier 
of E from false to true. Thus, when interrupt 7 
occurs, the runtime executes P, which sets the 
barrier of E to true; that unblocks task T, which 
performs the response to the interrupt, resets the 
barrier of E to false, and becomes suspended. 

We permit tasks to contain both “delay 
until” statements and entry calls. For our 
purposes, a task containing a “delay until” 
statement is periodic. A sporadic task contains a 
call on a protected entry whose barrier is set by 
an interrupt handler. Since we impose no upper 
limit on the interrupt hiteran ival tune, a sporadic 
task cannot be guaranteed to satisfy any periodic 
deadline. For this reason, sporadic tasks may not 
contain ‘delay until' statements. The Promela 
code checks that all periodic tasks meet their 
deadlines and that the response to every interrupt 
completes within the response tune. 

We have analyzed several systems containing 
both periodic and sporadic tasks, all on a 
SparcServer20 with 64 megabytes of memory. 

One is a toy pump control system [29] often 
used as a benchmark example, which our 
techniques handled in seconds. With some more 
complicated systems, however, the model of [16] 
encountered a state space explosion. We describe 
two such examples: 

1 . the Olympus attitude and orbital control 
system (AOCS) [30], 

2. a brewery control program [31]. 

A pump controller 

The pump control system has the following 
components: 



1 . four periodic tasks getting data from die four 
sensors and controlling die pump, 

2. a sporadic task, triggered by the interrupt 
from a high/low water level detector, diat 
controls die pump, and 

3. two protected objects for die pump and die 
interrupt interface. 

Verification of diis program took 20 seconds. 
The AOCS 

The AOCS design contains 17 protected 
objects, 4 sporadic tasks driven by interrupts 
(with short interarrival tunes), and 10 periodic 
tasks (widi relatively long periods). We were 
able to verify a reduced version widi all 10 
periodic tasks and only one sporadic task 
(roughly 1.5 hours of computation). Adding a 
second sporadic task resulted hi a state space 
explosion diat SPIN could not handle. 

A Brewery controller 

Our techniques successfully identified a 
timing error hi the brewery control program, but 
the analysis required some abstractions 
performed by hand, not merely the “standard” 
abstractions used to represent die pump 
controller. 

The brewery control program contains no 
interrupts. It consists of an alarm task suspended 
on a protected entry, several short-period tasks, 
and one long-period task that calculates a 
“pattern temperature.” One of the short-period 
tasks compares the actual temperature to the 
pattern and, if the difference between the 
temperatures is too great, opens the entry barrier 
to trigger the alarm. We model the decision 
about whether to trigger the alarm as a 
completely nondeterministic event (a 
conservative approximation). 

We may eliminate the long-period task 
altogether if we assume that the pattern 
temperature is constant. Under that assumption 
(also conservative) our methods took 6 minutes 
of computation to find a timing violation. 

If we do not assume that the pattern 
temperature is constant, the combination of a 
long-period task widi a short-period task 
nondeterministically triggering another task 
results in a state space explosion (as explained 
below). 

The size of our model’s state space is 
proportional to S p , where: 

1. P is the number of possible patterns of the 
periodic tasks’ arrival times. (A task arrives 


whenever it begins a new period.). P is 
roughly proportional to (MID), where M is 
die least common multiple of die task 
periods and interrupt interarrival times, and 
D is dieir greatest common divisor. 

2. S is die average number of non-deterministic 
choices exercised by the model during die 
execution of any one pattern of arrival times. 
A common source of non-determinism is die 
runtime process controlling task preemption. 
However, diis nondeterminism is usually 
restricted, since die control-delegating 
conditions in die runtime process are often 
mutually exclusive. Thus, die runtime 
process does not contribute much to die size 
of S. On die odier hand, nondeterministic 
behavior in a short-period task will increase 
S, since diis behavior is exercised in die 
many patterns where die task is running. 

Our problem with die brewery control 
program is diat die short-period task 
nondeterministically triggers the alarm, which 
increases S. We can still analyze the program if 
P is low, but including die long-period task 
increases P. This combination increases S p 
sufficiently to cause a state explosion. 

As for the interrupts, in [16] we model each 
interrupt by a Promela process representing a 
“quasi-task” that makes calls on die protected 
procedure that is its handler. The behavior of 
such a task is in many respects similar to die 
behavior of a periodic task that non- 
deterministically executes the interrupt handler 
and has a period equal to the interrupt’s 
minimum interarrival tune. 

4 Future research 

Our primary technical problem is how to 
optimize the model for efficient model-checking. 
The optimizations described in section 2 — the 
runtime status abstractions, the encoding of 
regions as pah s of integers — are specific to our 
problem domain and to the kinds of properties 
being analyzed. There is an extensive literature 
on general-purpose algorithms for abstractions 
and optimizations of untuned transition systems, 
and on the automated discovery of invariants. 
(See, for example, [21-24]). Future research will 
consider the applicability of that literature to our 
problem. 

Symbolic model checking is another 
possibility for dealing with state space explosion. 
Problems that do not yield to explicit search 



techniques can sometimes be solved by symbolic 
model checking (and vice versa). The state- 
machine model accepted by a symbolic model 
checker is typically quite low-level and 
constrained. Not all symbolic model checkers 
permit variables of integer type. But some, such 
as WSMV [9], are able to treat integers and 
certain integer operations symbolically by using 
special encoding techniques that permit efficient 
representation of addition and integer 
comparisons, and those are precisely the 
arithmetical operations our methods require. 
Tlius, WSMV is a promising engine for 
extending our results with symbolic model 
checking. 
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Abstract 

Linear hybrid automata are finite state automata 
augmented with real-valued variables. Transitions be- 
tween discrete states may be conditional on the val- 
ues of these variables and may assign new values to 
variables. These variables can be used to model real 
time and accumulated task compute time as well as 
program variables. Although it is possible to encode 
preemptive fixed priority scheduling using existing lin- 
ear hybrid automata models, we found it more general 
and efficient to extend the model slightly to include 
resource allocation and scheduling semantics. Under 
reasonable pragmatic restrictions for this problem do- 
main, the reachability problem is decidable. The proof 
of this establishes an equivalence between dense time 
and discrete time models given these restrictions. We 
next developed a new reachability algorithm that sig- 
nificantly increased the size of problem we could ana- 
lyze, based on benchmarking exercises we carried out 
using randomly generated real-time uniprocessor work- 
loads. Finally, we assessed the practical applicabil- 
ity of these new methods by generating and, analyz- 
ing hybrid automata models for the core scheduling 
modules of an existing real-time executive. This ex- 
ercise demonstrated the applicability of the technology 
to real-world problems, detecting several errors in the 
executive code in the process. We discuss some of the 
strengths and limitations of these methods and possi- 
ble future developments that might address some of the 
limitations. 

1 Introduction 

The first goal of the work described in this pa- 
per was to analyze the schedulability of real-time sys- 
tems that cannot be easily modeled using traditional 
scheduling theory. Traditional real-time task mod- 
els cannot easily handle variability and uncertainty in 
clock and computation and communication times, syn- 
chronizations (rendezvous) between tasks, remote pro- 
cedure calls, anomalous scheduling in distributed sys- 
tems, dynamic reconfiguration and reallocation, end- 
to-end deadlines, and timeouts and other error han- 
dling behaviors. 
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The second goal was to verify software implemen- 
tations of systems. Task schedulers and communica- 
tions protocols are reactive components that respond 
to events like interrupts, service calls, task comple- 
tions, error detections, etc. We would like to model 
important implementation details such as control logic 
and data variables in the code. We would like the map- 
ping between model and code to be clear and simple 
to better assure that the model really does describe 
the implementation. 

Discrete event concurrent process models are widely 
used to model control flow within and interactions be- 
tween concurrent activities. Classical discrete event 
concurrent process models do not deal with resource 
allocation and scheduling or data variables, which lim- 
its their usefulness for real-time systems and makes 
it awkward to model some implementation details. 
Classical preemptive scheduling models do not deal 
well with complex task sequencing and interaction, 
which limits their usefulness for describing distributed 
systems and implementation details. Discrete time 
models have been developed for real-time schedul- 
ing of concurrent processes[23, 13, 11, 31], and some 
work has been done on dense time real-time pro- 
cess algebras[10, 14], This paper describes the use of 
dense time linear hybrid automata models to perform 
schedulability analysis and to verify implementation 
code. 

The first problem we faced was the modeling of re- 
source allocation and scheduling behaviors using hy- 
brid automata. The applicability in principle of hy- 
brid automata to the scheduling problem was already 
known [4]. We wanted a model that would admit 
a variety of complex allocation as well as schedul- 
ing algorithms, e.g. load balancing, priority inheri- 
tance. We wanted to be able to change the allocation 
and scheduling algorithms easily without changing the 
models of the real-time tasks themselves. We wanted 
to minimize the number of states and variables added 
to model allocation and scheduling. We found it most 
general and efficient to extend the definition of hybrid 
automata to include resource allocation and schedul- 
ing semantics rather than try to model the scheduling 
function as a hybrid automaton. 

We use integration variables to record the accumu- 
lated compute time of tasks in preemptively sched- 



uled systems. Allowing integration variables is known 
to make the reachability problem undecidable[22, 17]. 
We were curious about whether analysis of real-time 
allocation and scheduling in distributed heterogeneous 
systems is itself a fundamentally difficult problem, or 
if general linear hybrid automata are more powerful 
than is really necessary for this problem. We were 
able to show that the reachability problem becomes 
decidable when some simple pragmatic restrictions are 
placed on the model. 

The second problem we faced was the computa- 
tional difficulty of performing a reachability analysis. 
We began our work using an existing linear hybrid 
automata analysis tool, HyTech[18], but found our- 
selves limited to very small models. We developed 
and implemented a new reachability method that was 
significantly faster, more numerically robust, and used 
less memory. However, our prototype tool allows only 
constant rates (not rate ranges) and does not provide 
parametric analysis. 

Using this new reachability procedure we were able 
to accomplish one of our goals: the modeling and ver- 
ification of a piece of real-time software. We devel- 
oped a hybrid automata model for that portion of the 
MetaH real-time executive that implements unipro- 
cessor task scheduling, time partitioning and error 
handling [1], We successfully analyzed these models, 
uncovering several implementation defects in the pro- 
cess. There are limits on the degree of assurance that 
can be provided, but in our judgement the approach 
may be significantly more thorough and significantly 
less expensive that traditional testing methods. This 
result suggests the technology has reached the thresh- 
old of practical utility for the verification of small 
amounts of software of a particular type. 

However, we do not believe existing reachability 
methods are adequate yet for schedulability analysis 
of real systems. In our judgement, we would need to 
be able to analyze systems having a few dozen tasks 
on a few processors in order for the technology to be- 
gin finding use in this area. We discuss approaches 
that might lead to such improvements. 

2 Resourceful Hybrid Automata 

A hybrid automaton is a finite state machine aug- 
mented with a set of real-valued variables and a set 
of propositions about the values of those variables. 
Figure 1 shows an example of a hybrid automaton 
whose discrete states are preempted, executing and 
waiting; and whose real- valued variables are c and t. 
Waiting is marked as the initial discrete state, and c 
and t. are assumed to be initially zero. 

Each of the discrete states has an associated set of 
differential equations, e.g. c = 0 and t = 1 for the 
discrete state preempted. While the automaton is in 
a discrete state, the continuous variables change at the 
rates specified for that state. 

Edges may be labeled with guards involving con- 
tinuous variables, and a discrete transition can only 
occur when the values of the continuous variables sat- 
isfy the guard. When a discrete transition does occur, 
designated continuous variables can be set to desig- 
nated values as specified by assignments labeling that 


edge. 

A discrete state may also be annotated with an 
invariant constraint to assure progress. Some dis- 
crete transition must be taken from a state before 
that state’s invariant becomes false. For example, the 
hybrid automaton in Figure 1 must transition out of 
state computing before the value of c exceeds 100. 

The hybrid automata of interest to us are called 
linear hybrid automata because the invariants, guards 
and assignments are all expressed as sets of linear con- 
straints. The differential equations governing the con- 
tinuous dynamics in a particular discrete state are re- 
stricted to the form x £ [l,u\ where [l, u] is a fixed 
constant interval (our current prototype tool is fur- 
ther restricted to a singleton rate, x = [/, l ] ) . 

We want to verify assertions about the behavior of 
a hybrid automaton. Although it is possible in general 
to check temporal logic assertions [4], we make do by 
annotating discrete states and edges with sets of linear 
constraints labeled as assertions. These constraints 
must be true whenever the system is in a discrete state 
or whenever a transition occurs over an edge. 

The cross-product construction used to compose 
concurrent finite state processes can be extended in 
a fairly straight-forward way to systems of hybrid au- 
tomata. The invariant and assertion associated with a 
discrete system state are the conjunction of the invari- 
ants and assertions of the individual discrete states. 
The guards, assertions and assignments of synchro- 
nized transitions are the conjunction and union of the 
guards, assertions and assignments of the individual 
discrete co-edges. If there is a conflict between the rate 
assignments of individual discrete states, or a conflict 
between the variable assignments of co-edges, then 
the system is considered ill-formed. Note that con- 
current hybrid automata may interact through shared 
real- valued variables as well as by synchronizing their 
transitions over co-edges. 

The application of interest in this paper is the anal- 
ysis and verification of real-time systems. Figure 1 
shows an example of a simple hybrid automata model 
for a preemptively scheduled, periodically dispatched 
task. A task is initially waiting for dispatch but may 
at various times also be executing or preempted. The 
variable t is used as a timer to control dispatching 
and to measure deadlines. The variable t is set to 0 
at each dispatch (each transition out of the waiting 
state), and a subsequent dispatch will occur when t 
reaches 1000. The assertion t < 750 each time a task 
transitions from executing to waiting (each time a task 
completes) models a task deadline of 750 time units. 
The variable c records accumulated compute time, it 
is reset at each dispatch and increases only when the 
task is in the computing state. The invariant c < 100 
in the computing state means the task must complete 
before it receives more than 100 time units of processor 
service, the guard c > 75 on the completion transition 
means the task may complete after it has received 75 
time units of processor service (i.e. the task compute 
time is uncertain and/or variable but always falls in 
the interval [75, 100]). 

In this example the edge guards selected and 
unselected represent scheduling decisions made at 




Figure 1 : A Hybrid Automata Model of a Preemptively Scheduled Task 


scheduling events (called scheduling points in the real- 
time literature) . These decisions depend on the avail- 
able resources (processors, busses, etc.) being shared 
by the tasks. There are several approaches to intro- 
duce scheduling semantics into a model having several 
concurrent tasks. 

Scheduling can be introduced using concepts taken 
from the theory of discrete event control [26]. A con- 
current scheduler automaton can be added to the sys- 
tem of tasks. The scheduling points in the task set 
become synchronization events at which the scheduler 
automaton can observe the system state and make 
control decisions. Many high-level concepts from dis- 
crete event control theory carry over into this domain, 
such as the importance of decentralized control and 
limited observability in distributed systems. 

Discrete event control theory provides an approach 
to synthesize optimal controllers, which in this do- 
main translates to the automatic construction of 
application-specific scheduling algorithms. However, 
classical discrete event control theory does not deal 
with time. The theory has been extended to synthesize 
nonpreemptive schedulers for timed automata [9, 2], 
but this excludes preemptively scheduled systems. It 
is possible to develop scheduling automata by hand 
using traditional real-time scheduling policies such as 
preemptive fixed priority. Some examples have been 
given in the literature, where each distinct ready queue 
state is modeled as a distinct discrete state of the 
scheduler automaton [4], This would allow a very large 
class of scheduling algorithms to be modeled, but the 
size of the scheduler automaton may grow combinato- 
rially with the number of tasks. 

It is possible to model preemptive fixed priority 
scheduling by encoding the ready queue in a variable 
rather than in a set of discrete states. A queue vari- 
able is introduced that will take on only integer values. 
At each transition where a task i is dispatched, 2' is 
added to this queue variable; at each transition where 
task i completes, 2 l is subtracted. The queue vari- 
able can be interpreted as a bit vector whose i th bit is 
set whenever task i is ready to compute. There is no 


separate scheduler automaton, the scheduling protocol 
is modeled using additional guards and states in the 
task automata. This is the approach we took when 
we started our work using HyTech. This encodes a 
specific scheduling protocol into each task model, and 
adds additional discrete states, variables and guards 
to the model. It is awkward to model any scheduling 
policy other than simple preemptive fixed priority. 

In the end, we found it simpler and more general 
to define a slightly extended linear hybrid automata 
model that includes resource scheduling semantics [28]. 
The discrete state composition of the task set is per- 
formed before any scheduling decisions are made. A 
scheduling function is then applied to the composed 
system discrete state to determine the variable rates 
to be used for that system state. In essence, the com- 
posed system discrete state is the ready queue to which 
the scheduling function is applied, very much analo- 
gous to the way run-time scheduling algorithms are 
applied in an actual real-time system. It is not nec- 
essary to have different discrete states for preempted 
and computing, since this information is now captured 
in the variable rates. It is not necessary to model a 
scheduling algorithm as a finite state control automa- 
ton added to the system, it is not necessary to encode a 
specific scheduling semantics into the task automata. 
One simply codes up a scheduling algorithm in the 
usual way and links it with the rest of the reachabil- 
ity analysis code. This approach significantly reduces 
the number of discrete states in the model (from 3* 
for our HyTech models to 2 f for our extended models, 
where t is the number of tasks). This also simplifies 
the modeling of the desired scheduling discipline. The 
details of this model and its semantics are recorded 
elsewhere[28] . 

3 Decideability 

Most traditional real-time schedulability problems 
are solvable in polynomial time or are NP-complete. 
However, hybrid automata models that allow multiple 
rates and integration variables are undecideable[22, 
17], The hybrid automata models we are using are 
much more powerful than traditional allocation and 



scheduling models, and most existing tasking and 
scheduling models can be viewed as special cases of 
the more general hybrid automata model. This raises 
the question of whether the schedulability problem for 
complex interacting tasks that are dynamically allo- 
cated in distributed heterogeneous systems is in fact 
undecideable, or whether models of such systems are 
decideable special cases of the more powerful linear 
hybrid automata models. 

The undecideability of hybrid automata reachabil- 
ity analysis was proved by reducing the reachability 
problem for two-counter machines, which is known to 
be undecideable, to the reachability problem for hy- 
brid automata[22, 17]. The construction used in the 
proof is fairly straightforward in our slightly extended 
model and can be accomplished using a single pro- 
cessor. However, a pragmatic real-time system de- 
signer would reject the theoretical construction as a 
bad design because it relies in places on exact equal- 
ity comparisons between timers and accumulated com- 
pute times. In a real system, these would be regarded 
as race conditions or ill-defined behaviors. The prob- 
lem becomes decideable given a few simple practical 
restrictions, which are captured in the following theo- 
rem. 

Theorem 1 The reachability problem is decideable 
for resourceful linear hybrid automata if the following 
conditions hold. 

• The set of possible outputs of the scheduling func- 
tion for each possible system discrete state is finite 
and enumerable. 

• For every task activity integrator variable, the 
rate interval remains fixed between resets of that 
integrator (i.e. the scheduler does not dynamically 
reallocate any task activity in mid-execution to a 
new resource having a different rate for that ac- 
tivity). 

• For every task activity integrator variable, every 
edge guard is a set of rectangular constraints of 
the form x £ [Z, u] , and either the edge guard has 
a non-singular interval (x £ [Z, u] with l < u) 
or else the rate interval for x is non- singular ( i. e. 
system behavior does not depend on exact equality 
comparisons with exact drift-free clocks or execu- 
tion rates). 

• However, we allow as a special exception task ac- 
tivity integrator variables with singular rate inter- 
val and singular rectangular edge guards, provid- 
ing the integrator variable is only reset or stopped 
or restarted at a transition having at least one 
edge guard y £ [to, to] with [to, to] and y singu- 
lar (y may but need not be x), and for every such 
singular constraint on that edge x = ky for some 
positive integer k (i.e. some types of noninteract- 
ing or harmonically interacting behaviors may be 
modeled exactly). 

This result should not be surprising. The ability 
to test for exact equality is known to add theoretical 


power to dense time temporal logics [3], and similar 
restrictions are known to make certain other hybrid 
automata models decideable[25]. The proof of this 
theorem, which we provide elsewhere[28], is by reduc- 
tion to a discrete time finite state automaton. 

4 Reachability Analysis 

A state of a linear hybrid automaton consists of a 
discrete part, the discrete state at some time t; and 
a continuous part, the real values of the variables at 
time t. It turns out that, although this state space 
is uncountably infinite, the reachable state space for 
a given linear hybrid automaton is a subset of the 
cross-product of the discrete states with a recursively 
enumerable set of convex polyhedra in 5ft" (where n is 
the number of variables) [4] . A region of a linear hy- 
brid automaton is a pair consisting of a discrete state 
and a convex polyhedron, where convex polyhedra can 
be represented using a finite set of linear constraints. 
Model checking consists of enumerating the reachable 
regions for a given linear hybrid automaton and check- 
ing to see if they satisfy the assertions. 

Figure 2 depicts the basic sequence of operations 
that, given a starting region (a discrete state and a 
polyhedron defining a set of possible values for the 
variables), computes the set of values the variables 
might take on in that discrete state as time passes; 
and computes a set of regions reachable by subsequent 
discrete transitions. 

The first step is the computation of the time suc- 
cessor polyhedron from the starting polyhedron (of- 
ten called the post operation). For each point in the 
starting polyhedron, the time successor of that point 
is a line segment beginning at that point whose slope 
is defined by the variable rates specified for the dis- 
crete state. This is the set of variable values that 
can be reached from a starting point by allowing some 
amount of time to pass. The time successor of the 
starting polyhedron is the union of the time successor 
lines for all points in the starting polyhedron. A ba- 
sic result of linear hybrid automata theory is that the 
time successor of any convex polyhedron is itself a con- 
vex polyhedron (which in general will be unbounded 
in certain directions) [4] . 

The second step is the intersection of the time suc- 
cessor polyhedron with the invariant constraint asso- 
ciated with the discrete state. Polyhedra are easily 
intersected by taking the union of the set of linear 
constraints that define the two polyhedra. This is the 
time successor region that is feasible given the invari- 
ant specified for the discrete state. 

The remaining steps are used to compute new re- 
gions reachable from this feasible time successor re- 
gion by some transition over an edge. For each edge 
out of the current discrete state, the associated guard 
is first intersected with the feasible time successor re- 
gion. This polyhedron, if nonempty, defines the set 
of all variable values that might exist whenever the 
discrete transition could occur. Any variable assign- 
ments associated with the edge must now be applied 
to this polyhedron. This is done in two phases. First, 
a variable to be assigned a new value x := l is uncon- 
strained (often called the free operation). This oper- 
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Figure 2: Hybrid Automata Reach Forward Operations 


ation leaves unchanged the relationships between all 
other variables, i.e. the polyhedron is projected onto 
the subspace 5ft” of the remaining variables. This 
result is then intersected with the constraint x = l. 
This polyhedron, together with the discrete state to 
which the edge goes, is a new region for which the 


above steps may be repeated. In general a set of as- 
signments whose right-hand sides are linear formula 
are allowed, with some restrictions. The variables to 
be assigned are unconstrained and the resulting poly- 
hedra are then intersected with the appropriate linear 
constraints in some order. With care, fairly complex 




sequences of assignments to program variables can be 
modeled on a single edge [30], 

The overall method begins at the initial region of 
a hybrid automaton. The operations described above 
are applied to enumerate feasible time successor re- 
gions and the new regions reachable from these via 
discrete transitions. As new regions are enumerated, 
they must be checked to see if they have been visited 
before (otherwise the method will not terminate even 
when there are a finite number of regions). This is 
done by comparing the discrete states of regions for 
equality, and by checking to see if the new polyhedron 
is contained in the polyhedron of a previously visited 
region. 

The earliest reachability tool of which we are aware, 
HyTech, represented polyhedra as finite sets of linear 
constraints [4]. Operations on polyhedra used quan- 
tifier elimination, a method to manipulate and make 
decisions about systems of linear constraints in which 
some of the variables are existentially quantified. Sub- 
sequent tools, Polka and a later version of HyTech, 
used a pair of representations: the traditional system 
of linear constraints together with polyhedra gener- 
ators consisting of sets of vertices and rays [16, 18]. 
Different operations required during reachability are 
more convenient in the different representations, and 
methods are used to convert between the two as 
needed. 

Both of these methods are subject to the theoreti- 
cal risk that some polyhedra operations may require a 
combinatorial amount of time. Another potential per- 
formance problem occurs when the reachable discrete 
state space is completely enumerated first followed by 
an enumeration of the polyhedra. This might result 
in enumerating discrete states that are actually not 
reachable due to edge guards involving the continuous 
variables. Finally, in our experiments we found that a 
significant fraction of a set of benchmark schedulabil- 
ity problems we tried to solve using HyTech resulted 
in numeric overflow errors. 

We developed a new set of algorithms for the poly- 
hedra operations used during reachability analysis and 
implemented a prototype on-the-fly reachability anal- 
ysis library. Our prototype operates on lists of linear 
constraints of the form l < e < u where l and u are 
fixed constant integer bounds and e = c\Xi + C2X2 + ... 
is a linear formula with fixed constant integer coeffi- 
cients. Our current algorithms restrict variable rates 
to be fixed scalar constants, x = i rather than the 
more general x £ [ l,u ]. 

We convert a polyhedron P into Pos (.(/ ’, x), the 
time successor of P given a vector of variable rates 
x, by applying the two steps 

1. Let each constraint h < et < m where d L / 0 be 
written so that d L >0, which can be achieved by 
multiplying the constraint by -1 if needed. For 
each distinct pair of constraints 

^ ’d rq 
h — e j — u j 

where e'j > 0 and dj > 0, add to the set the 


constraint 

djli — diUj < djei — diej < e'jUi — dilj 

2. Replace each constraint l < e < u, where e > 0 by 
l < e < 00 . 

We compute Free(P, x), the result of unconstraining 
variable x in polyhedron P, using the two steps 

1 . Let each constraint l < e < u in P where e has an 
instance of x be written in the form l < cx — e' < 
u, where e' involves the remaining variables and 
their coefficients and c > 0. For every distinct 
pair of such constraints in P 

h < CiX — ej < Ui 
Ij < CjX — Cj < Uj 

combine the two in a way that cancels the x terms, 
adding to Free)/ 3 , x) the constraint 

Cjli CiUj - Ci€j CjG% "d C j Uj C^lj 

2. Each constraint l < e < u where e has no in- 
stances of variable x is added to Free)/ 3 , 2 ;). 

These algorithms might be viewed as general- 
izations of the difference methods used for timed 
automata [12, 8] and exhibit some similarity to 
the pragmatic algorithm used earlier for quantifier 
elimination [4]. Our prototype invokes a Simplex al- 
gorithm as part of the operations to test for feasibility 
and containment. We use a bounds tightening pro- 
cedure to reduce the size of the constraint list after 
certain operations and to rapidly detect most infeasi- 
ble polyhedra. Simplex-based reduction and feasibil- 
ity testing is only applied when the bounds tightening 
procedure is ineffective. Details of our reachability 
analysis methods and implementation and proofs of 
correctness are documented elsewhere[29]. 

We benchmarked our prototype tool against 
HyTech and Verus[ll] (a discrete timed automata 
reachability analysis tool that uses BDD techniques) 
using randomly generated uniprocessor workloads con- 
taining mixtures of periodic and aperiodic tasks. Fig- 
ure 3 shows the percentage of problems that were 
solved by each of the tools, together with the primary 
reasons that solution was not achieved. Figure 4 com- 
pares the time required for solution for problems that 
were solved by all the tools using a logarithmic scale (a 
point appears for both HyTech and our prototype only 
for problems that were solved by both). We further 
increased the size of model we could analyze by ap- 
plying some results from traditional scheduling theory 
to simplify the models, and by using a simple partial 
order reduction technique, these results are reported 
elsewhere[29], 

5 Verifying the MetaH Executive 

MetaH is an emerging SAE standard language for 
specifying real-time fault-tolerant high assurance soft- 
ware and hardware architectures [1, 24, 27], Users 
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Figure 3: Percentage of Generated Problems That Were Solved 
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specify how software and hardware components are 
combined to form an overall system architecture. This 
specification includes information about one or more 
configurations of tasks and message and event connec- 
tions; and information about how these objects are 
mapped onto a specified hardware architecture. The 
specification includes information about timing behav- 
iors and requirements, fault and error behaviors and 
requirements, and partitioning and safety behaviors 
and requirements. 

Our current MetaH toolset, illustrated in Figure 5, 
can generate and analyze formal models for schedula- 


bility, reliability, and partition isolation. The toolset 
can also configure an application-specific executive to 
perform the specified task dispatching and schedul- 
ing, message and event passing, changes between alter- 
native configurations, etc. Unlike many conventional 
systems that rely on a large number of run-time ser- 
vice calls to configure a system by dynamically cre- 
ating and linking to tasks, mailboxes, event channels, 
timers, etc., our toolset builds most of this informa- 
tion into an application-specific executive. There are 
relatively few run-time service calls, and the effects of 
these are tailored based on the specified application 
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Figure 5: MetaH Toolset 


architecture and requirements. 

Our MetaH executive supports a reasonably com- 
plex tasking model using preemptive fixed priority 
scheduling theory [5, 6, 7]. Among the features rele- 
vant to this study are period-enforced aperiodic tasks, 
real-time semaphores, mechanisms for tasks to initial- 
ize themselves and to recover from internal faults, and 
the ability to enforce execution time limits on all these 
features (time partitioning) . Slack stealing in support 
of aperiodic and incremental tasks is also supported, 
but as we will mention later these were not modeled 
or verified. 

Figure 6 shows the high-level structure of the 
MetaH executive. The core task scheduling operations 
are implemented by module Threads, e.g. start, dis- 
patch, complete. These operations implement tran- 
sitions between the discrete task scheduling states, 
e.g. dispatch may transition a task from the await- 
ing dispatch state to the computing state. These op- 
erations must take into account details such as the 
task type, optional execution time enforcement, event 
queueing, etc. Module Threads invokes operations 
in module Time_Slice, which encapsulates arithmetic 
operations and tests on two execution time accumula- 
tors maintained by the underlying RTOS and hard- 
ware for each task: an accumulator that increases 

while a task executes, and a time slice that decreases 
while a task executes. Time_Slice may set these vari- 
ables to desired values using services provided through 
the MetaH RTOS interface. If time slicing is en- 
abled for a task, then a trap will be raised by the 
underlying hardware and RTOS when the time slice 
reaches zero. This trap is handled by one of the oper- 
ations in Threads. Module Clock_Handler is periodi- 
cally invoked by the underlying system (it is the han- 


dler for a periodic clock interrupt) and makes calls to 
Threads to dispatch periodic tasks and start and stop 
threads at mode changes. Modules Events, Modes 
and Semaphores contain data tables and operations 
to manage user-declared events, dynamic reconfigura- 
tion, and semaphores. 

We produced hybrid automata models for the 
Threads and Time_Slice modules, about 1800 lines 
of code. We did not write a separate model using a 
special modeling language, instead we inserted calls 
to build the model into the executive code itself. For 
example, in the code that implements the dispatch 
operation there is logic to decide if a task can be 
dispatched, assignments to change program variables, 
and calls to set the time slice and execution time coun- 
ters. Into this code we inserted a call to a modeling 
procedure to create an edge between the correspond- 
ing states of the linear hybrid automata model. The 
guards for this edge are the conditional expressions 
appearing in the code, and the assignments on this 
edge are the assignments appearing in the code. This 
provides a high degree of traceability between the im- 
plementation and the model. 

The generation of the hybrid automata models re- 
sembled all-paths unit testing. We developed several 
simple application specifications that included most 
(but not all) of the tasking features. We wrote a test 
driver that exercised all relevant paths in the core 
scheduling modules. For each application specifica- 
tion, the test driver thus triggered the generation of a 
linear hybrid automata model of the possible behav- 
iors of the core scheduling operations for a particular 
combination of tasks and features. 

The conditions we checked during reachability 
analysis were that all deadlines were met whenever 











Figure 6: MetaH Executive Structure 


the schedulability analyzer said an application was 
schedulable; no accessed variables were unconstrained 
(undefined) and no invariants were violated on entry 
to a region; and no two tasks were ever in a semaphore 
locking state simultaneously. Assertion checks appear- 
ing in the code were modeled by edges annotated with 
assert False. 

We also collected information about which edges 
were used by some transition during reachability anal- 
ysis and compared this with all the possible edges that 
might be created (all instances of calls inserted into 
the code to create edges). This allowed us to insure 
that all modeled portions of the code were covered by 
at least one reachability analysis. 

A total of 14 real-valued variables and 15 discrete 
states were defined to model each task. No single task 
model used all 14 variables and 15 states, different 
task types with different specified options used differ- 
ent combinations. Figure 7 shows the simplest lin- 
ear hybrid automata model we generated, a periodic 
task with period and deadline of lOOOOOus, compute 
time between 0 and 90000us, recovery time between 
0 and lOOOOus. States are also annotated with pro- 
cessor scheduling priorities, which are not shown here. 
The variable rates were derived from the scheduling 
priorities by the analysis tool, which used preemptive 
fixed priority scheduling semantics for this study. Ta- 
ble 1 summarizes the complete set of applications we 
analyzed. A more detailed discussion of the modeling 
methods and results is provided elsewhere[30] . 

We discovered nine defects in the course of our ver- 
ification exercise. Four of these were tool defects, two 
that could cause bad configuration data to be gener- 
ated and two that could cause erroneously optimistic 
schedulability models to be generated. Six of these 
defects could cause errors only during the handling 
of application faults and recoveries, three of these six 
only in the presence of multiple near-coincident faults 
and recoveries. In our judgement, of the nine defects 
we found, one would almost certainly have been de- 
tected by moderately thorough requirements testing, 
while three would have been almost impossible to de- 


tect by testing due to the multiple carefully timed 
events required to produce erroneous behavior. The 
other five may have been detected by thorough re- 
quirements testing of fault and recovery features, pro- 
viding the tester thought about possible execution 
timelines and arranged for tasks to consume carefully 
selected amounts of time between events. 

There are a number of significant limitations on the 
degree of assurance provided. In our initial exercise, 
we chose not to model many behaviors that could have 
been modeled in a fairly straight-forward way, e.g. 
mode changes, inter-processor communication proto- 
col, non-preemptable executive critical sections. In 
some cases different behaviors and subsystems can be 
modeled and analyzed almost independently, but it is 
not clear at what point the reachability analysis will 
become intractable as the extent of the model grows. 
Some behaviors might be more difficult to model, e.g. 
slack scheduling. The MetaH processor interface, un- 
derlying RTOS and hardware are unlikely to be fully 
model-able for a variety of practical and technical rea- 
sons. The MetaH tools were not verified, only a few 
specific generated modules and reports for a few ex- 
ample applications. Although our approach provides 
good traceability between code and model, there is 
still a very real possibility of modeling errors. The 
reachability analysis tool may contain defects; we dis- 
covered two in our tool in the course of this work. 
The modeled code does not change from application 
to application, and the analyzed applications fully ex- 
ercised the code model, but to rigorously assert this 
code is correct for all possible applications would re- 
quire some sort of induction argument. Even if the 
source code is correct, defects in the compiler, linker 
or loader software could introduce defects into the ex- 
ecutable image. 

Nevertheless, we estimate that the effort required 
for this exercise was roughly comparable to that re- 
quired for traditional unit testing, but the results were 
more thorough than would have been achieved using 
traditional requirements testing. The method must be 
used in conjunction with traditional verification tech- 















niques such as testing, but it is at least intuitively 
reasonably easy to distinguish requirements that will 
be verified using hybrid automata from requirements 
that must be verified using other techniques. 

6 Future Work 

Our experience leads us to believe that linear hy- 
brid automata are very powerful and well-suited for 
this domain. We were able to achieve one of our goals, 
the modeling and verification of a piece of real-world 
real-time software, with a number of limitations. We 
do not believe we have achieved the other goal yet, 
modeling and schedulability analysis for complex dis- 
tributed systems of real-world size. However, there are 
a number of potential future developments that might 
reduce the verification limitations and provide useful 
schedulability analysis capabilities. 

It should be possible to use the set of reachable 
regions produced by the analysis tool to automatically 
generate tests. This could significantly reduce the cost 
and increase the quality of requirements testing (which 
might still be required by the powers-that-be) . Such 
tests could also detect defects that could not be found 
by model analysis, such as defects in the compiler, 
linker, loader, RTOS or hardware. One of the issues 
that must be confronted is the ease of constructing, 
running and observing the results of tests; for example, 
in theory one might encounter transitions in the model 
that occur only when two values are extremely close, 
which could be practically impossible to do in a test. 
Another issue is that such tests would not take into 


account the internal logic of unmodeled modules such 
as the RTOS; a systematic method for testing multiple 
points within each reachable polyhedron might help 
address this. 

There are a number of potentially useful improve- 
ments in analysis methods and tools. Approximation 
and partial order methods might significantly increase 
the size of the model that could be analyzed[16, 19, 
15, 29]. Preprocessing models to modify numeric pa- 
rameters in certain ways can result in much more eas- 
ily solved models [29]. It is possible to apply theo- 
rem proving methods to linear hybrid automata [21], 
and some work has been done on dense-time process 
algebras[10, 14]. Decomposition and induction meth- 
ods currently being explored for discrete state models 
might be extensible to linear hybrid automata. There 
are a number of possible ways to visualize and navigate 
the reachable region space that would be of practical 
assistance during model development and debugging 
and during reviews. Concise APIs and support for in- 
line modeling could reduce both the modeling effort 
and the number of modeling defects. 

Changes will inevitably be required to the design, 
implementation and verification processes to make 
good use of these methods. Much of the benefit of 
other formal methods has been due to subsequent 
changes in development methods that resulted in more 
verifiable and defect-free specifications, designs and 
code in the first place. An important and not com- 
pletely technical question is how verification processes 
might be changed to beneficially use these methods. 



Description 

Discrete 

States 

Distinct 

Polyhedra 

Sparc Ultra-2 
CPU Seconds 

one periodic task 

7 

7 

0 

one periodic task, enforced execution time limits 

7 

10 

0 

one periodic task, enforced execution time limits, one semaphore 

8 

29 

15 

one period-enforced aperiodic task 

9 

18 

0 

one period-enforced aperiodic task, enforced execution time limits 

9 

27 

2 

one period-enforced aperiodic task, enforced execution time limits, one 
semaphore 

11 

124 

125 

two periodic tasks 

36 

60 

3 

two periodic tasks, enforced execution time limits 

36 

108 

24 

two periodic tasks, one with period transformed into two pieces, 

41 

97 

10 

two periodic tasks, one shared semaphore 

48 

118 

36 

two periodic tasks, one with period transformed into two pieces, enforced 
execution time limits 

41 

174 

87 

two periodic tasks, one with period transformed into four pieces, enforced 
execution time limits, recovery limit greater than compute limit 

40 

334 

103 

two tasks, one periodic and one period-enforced aperiodic 

44 

623 

115 

two periodic tasks, one with period transformed into four pieces, enforced 
execution time limits 

41 

351 

170 

two tasks, one periodic and one period-enforced aperiodic, enforced ex- 
ecution time limits 

44 

425 

184 

two tasks, one periodic and one period-enforced aperiodic, one shared 
semaphore 

70 

638 

840 

two periodic tasks, one with period transformed into two pieces, enforced 
execution time limits, one shared semaphore 

55 

963 

5658 


Table 1: Modeled Applications 


What evidence would be required, for example, to con- 
vince a development organization or regulatory au- 
thority to replace selected existing verification activ- 
ities with modeling and analysis activities, or to add 
modeling and analysis to current verification activi- 
ties? 
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Orpheus: A Self-Checking Translation Tool Arrangement 
for Flight Critical Hardware Development 


David Greve* Matthew Wilding* 

Abstract 

We describe Orpheus , our vision for a de- 
velopment and verification environment for 
flight critical hardware devices. Orpheus pro- 
vides an arrangement of translation tools that 
are self-checking and that integrate synthe- 
sis, high-speed simulation, and formal anal- 
ysis. Implementation of the Orpheus ar- 
chitecture would allow tight integration of 
these formerly distinct activities and facil- 
itate the use of formal analysis in flight- 
critical system certification. Further, flexibil- 
ity in the choice of design representation pro- 
vided by Orpheus would support both current 
design practice and hardware/software code- 
sign. This paper describes the notion of self- 
checking tools, the Orpheus tool architecture, 
and how commercially-available tools could be 
used to implement such a system. 

1 Current Practice 

1.1 Background 

Certification of flight critical systems is to- 
day a labor-intensive, manual process. Verifi- 
cation and certification of flight critical soft- 
ware and application-specific integrated cir- 
cuits (ASICs) require an almost heroic effort 
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of intense inspections and process documenta- 
tion. The complexity of systems and devices 
will increase, because increases in cockpit au- 
tomation and application integration offer im- 
portant safety benefits, and because astonish- 
ing improvements in digital computing tech- 
nology can potentially improve performance 
and decrease cost. The current approach to 
verification and certification may not be ade- 
quate in the face of this increased complexity. 
In order to reap fully the safety benefits of 
these technological advances we must develop 
new methods for verification and certification 
of flight critical devices. 

Several recent developments permit a supe- 
rior approach to verification and certification. 
First, flight critical ASICs can now be de- 
veloped using standard hardware description 
languages (HDLs) because recent advances in 
equivalency-checking tools provide an inde- 
pendent check that synthesis preserves func- 
tional correctness. Second, theorem proving 
tools have emerged that enable mechanical 
formal analysis of device properties. Third, 
translation tools are emerging that allow the 
integration of mathematical analysis into the 
conventional fabrication/simulation-based de- 
velopment environment. 

1.2 Flight Critical HDL Use 

Modern hardware devices are typically devel- 
oped using one of several hardware description 
languages (HDLs), such as Verilog or VHDL. 
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Figure 1: Fabrication toolsets for flight critical 
HDL provide self-checking 

In the area of flight critical hardware, how- 
ever, this has been the case only within the last 
few years. The delay in adopting these design 
techniques has been a result of concerns about 
the reliability of the process by which an im- 
plementation expressed in an HDL is used to 
fabricate the actual device. The complexity of 
HDLs means that tools that manipulate HDL 
designs are complex. As a result, the move to- 
ward using standard HDLs was hindered be- 
cause requirements could not be traced to the 
device without trusting the synthesis tools and 
supporting libraries. 

Fortunately, tools now exist that allow 
highly-dependable HDL fabrication. Figure 1 
shows how 4 fabrication-oriented tools can be 
used to make the fabrication process immune 
from corruption by a fault in any single tool. 
A synthesis tool converts an HDL design into 
a netlist, and a place- and-route tool converts 
the netlist into GIF data that can be fabri- 
cated. The GIF data is checked against the 
netlist using an LVS (layout- versus-schematic) 
tool. The netlist is checked against the VHDL 
model using equivalence-checking tools. 

The dependability of the connection be- 
tween the design and physical device afforded 
by an independent tool chain as presented in 
Figure 1 has changed how flight critical hard- 
ware is developed. Incorporation of this in- 


Figure 2: Designers typically build two device 
models 

novation into the development process has al- 
lowed developers of airborne hardware to ben- 
efit from modern design practices such as syn- 
thesis and optimization. 

1.3 Device simulators 

It is commonly the case that a high-speed sim- 
ulator is developed in parallel with an HDL 
model of a device. There are several reasons 
for this. 

• Execution of the VHDL model is often too 
slow to support testing activities. This is 
especially true for large test suites such as 
are typical for regression testing. 

• Software or other parts of the system that 
rely on the device must be developed be- 
fore the HDL model is complete. 

High performance is critical for device sim- 
ulators, so simulators of this type are typically 
constructed using a high-level language (HLL) 
such as C or C++ for which there are compil- 
ers that generate efficient code 1 . 

'Multiple simulators are routinely built during de- 
vice development. For example, a microcoded mi- 
croprocessor’s simulators would typically include both 
an instruction-level simulator and a microarchitecture 
simulator. The device simulator we are describing here 
is a low-level, cycle-accurate simulator. 






The required functionality of complex com- 
putational devices is typically implemented us- 
ing a combination of hardware and software, 
and an early design decision in the develop- 
ment of these systems is where to draw the 
line between these two kinds of implementa- 
tions. The distinction between hardware and 
software in implementions adds complexity to 
these systems, since it requires that an inter- 
face be defined. Furthermore, this interface 
between hardware and software can change 
during a design cycle as implementation is- 
sues make clearer the tradeoffs between im- 
plementing various functions in hardware or 
in software. It would therefore be desirable 
to develop hardware and software using the 
same languages and tools, and delay decisions 
about the exact form in which they will be im- 
plemented. Designing could be done, for ex- 
ample, using C. Functions whose design will 
ultimately appear in hardware can be fabri- 
cated using the HDL representation. This has 
the potential to simplify development efforts 
since no hardware/software interface need be 
considered during development. 

Figure 2 shows the artifacts resulting from 
current practice: two models that are expected 
to be identical in substance but that are writ- 
ten in different languages. This is typical of 
the current state-of-the-art design practice for 
airborne hardware devices. 

2 Formal Analysis 

Current certification processes provide some 
hard-to-quantify assurance that critical air- 
borne hardware devices meet their require- 
ments. Teams of inspectors “walk through” a 
design, assessing whether the implementation 
indeed meets the stated requirements. This 
process generates a paper trail that documents 
the level of effort of the inspectors and ensures 
that all relevant parts of the design have in 


fact been examined against the requirements. 
For complex designs this type of examination 
is very labor-intensive, but there is currently 
no viable alternative. Even so, the quality of 
the device is, to a large extent, measured in- 
directly via the inspection process. 

Several aspects of the current process for de- 
veloping and certifying safety-critical devices 
are not ideal. It would be better if certifica- 
tion practice measured the quality of the de- 
vice directly, rather than measuring the effort 
applied to the verification. Further, as the 
trend is toward using more complex devices for 
critical airborne activities, current verification 
and certification threaten to become increas- 
ingly inadequate. It has long been hoped that 
mathematical reasoning — rather than careful 
documentation of the efforts of inspectors — 
could ferret out design flaws more effectively 
than manual inspections. The potential for 
establishing by direct, formal reasoning that 
a device meets its requirements has obvious 
appeal, and is increasingly recognized as a vi- 
able verification methodology by certification 
authorities. 

Mathematical proofs about computing de- 
vices tend to be very complex and detail- 
laden, which makes them impractical to de- 
velop or check by hand. There has been con- 
siderable research applied to the development 
of automated theorem provers that are ca- 
pable of checking and/or generating mathe- 
matical proofs. Leading tools include ACL2, 
HOL, and PVS, and each is increasingly find- 
ing application in industrial settings where 
safety or wide product distribution makes es- 
tablishing design correctness imperative. Var- 
ious verification projects have used theorem 
provers to analyze computer system models 
[1, 2, 4, 6, 8, 13, 14, 17]. A dramatic re- 
cent example of the possibilities of applying 
formal analysis to computing systems is the 
ACL2-checked verification of AMD’s Athlon 
(formally “K7”) floating-point operations [16]. 
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Figure 3: Formal analysis requires designers 
build yet another model. 


The increased industrial use of automated 
theorem provers results from improvements in 
the tools themselves and increased availability 
of reusable libraries of results [7, 9, 16]. Al- 
though we expect these tools will be increas- 
ingly common, poor integration with other as- 
pects of the design environment remains an 
impediment to their adoption [12]. We be- 
lieve that formal analysis will become perva- 
sive only when the tools are properly integrated 
with other aspects of the design environment. 

Figure 3 identifies the artifacts resulting 
from a process augmented to support formal 
verification: three models of the same device 
written in three different languages each sup- 
porting its own development or verification ac- 
tivity. In a recent effort Rockwell Collins de- 
veloped three separate device models — one 
each for fabrication, simulation, and formal 
analysis — in order to benefit from each of 
these activities [11]. However, the high cost of 
building and maintaining models alone makes 
this approach unsustainable. Even more trou- 
blesome is that the multiple models might be 
inconsistent with each other, so a property 
proved about the formal model or the observ- 
able behavior of the simulator used to develop 
other parts of the system might not be re- 
flected in the actual fabricated device. 



Figure 4: Executable formal models reduce the 
number of models 


3 Orpheus 

We propose a comprehensive development 
and verification environment for safety-critical 
hardware devices called Orpheus. In Greek 
mythology, Orpheus subdues the fearsome, 
three-headed, dog-like Cerebus. As we 
have seen, verification and certification of 
increasingly-complex safety-critical devices re- 
quires us to overcome another three-headed 
challenge: to support device fabrication, high- 
speed simulation, and formal analysis in an in- 
tegrated way. Orpheus does so without requir- 
ing the development of multiple models that 
are expensive and possibly inconsistent. The 
Orpheus approach can be integrated into cur- 
rent approaches for flight critical device devel- 
opment. The Orpheus tools are self-checking, 
so as to guarantee that no single translation 
tool can introduce an error into the verifica- 
tion process. The approach allows flexibility 
of design paradigm: it supports HDL devel- 
opment, hardware/software codesign, and de- 
signs derived from formal specification. 

3.1 Reducing Three Models to 
Two 

In part to address the issue of multiple distinct 
models, Rockwell Collins recently developed 
techniques that allow formal models written 
in a. particular style in the ACL2 logic to be 



compiled into C for use as a high-speed simu- 
lator [10, 18]. This work effectively combines 
the formal and simulator models, thereby re- 
ducing the number of models from three to 
two. Figure 4 shows the impact of this inno- 
vation. The integration increases confidence 
in the validity of the unified model, since the 
same model is used both as a simulator and 
as a target of formal analysis. This impor- 
tant capability — high speed execution of for- 
mal logic definitions — has since been added to 
two theorem proving systems: 

• A recent PVS extension provides a trans- 
lator from PVS functions into Common 
Lisp. Rockwell Collins’ preliminary tests 
using a version of the benchmark from [18] 
in PVS 2.3 [15] indicate that execution 
speeds are within an order of magnitude 
of the speed of a model written conven- 
tionally in C. We expect that PVS will 
ultimately develop the capability to inte- 
grate models expressed in the PVS logic 
into other tools. 

• Single-threaded objects have been added 
to ACL2 2.4 and provide for high- 
speed execution of certain definitions [5]. 
Single-threaded objects are an extension 
of the notion of ACL2 “state” that per- 
mits the introduction of user-defined state 
elements. ACL2 enforces syntactic re- 
strictions on the use of single-threaded 
objects to guarantee that the optimiza- 
tions are legitimate. Rockwell Collins’ 
experiments suggest that complex de- 
vice models can be expressed despite the 
syntactic restrictions enforced on single- 
threaded objects, indicating that these 
restrictions do not make the ACL2 lan- 
guage impractical. Rockwell Collins has 
recently shown that ACL2 code can be 
integrated with other tools [18]. 
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Figure 5: Formal models could provide a sin- 
gle, unified model 


3.2 Reducing Two Models to 
One 

An approach has recently emerged that poten- 
tially allows the integration of high-speed sim- 
ulation models and device designs written in 
HDL. Several commercial tools are now avail- 
able to translate high-level language (HLL) 
models into HDL models suitable for fabrica- 
tion. Among the leading tools of this type 
are CynApps’ C++- to-Verilog converter and 
C level’s C-to-HDL converter, which gener- 
ates either Verilog or VHDL. These tools pro- 
mote an HLL-based design methodology that 
integrates simulation and fabrication. The ex- 
istence of such tools and the emerging push 
for system level design and hardware/software 
codesign practices suggest that the commer- 
cial world will continue to develop and improve 
these tools. 

The ability to compile a formal model into a 
simulation model, as described above, reduces 
the three models to two. Figure 5 suggests 
an obvious way to reduce the two models to 
one, by compiling the simulation model into 
a fabrication model expressed in an HDL. We 
discuss in Section 3.4 our initial testing of one 
of these tools, C level’s C-to-HDL tool, and 
this experience suggests that Orpheus may be 
a realistic path for some applications. 
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Figure 6: The Orpheus translation circle uses 
a single model to combine fabrication, high- 
speed simulation, and formal analysis 


3.3 Closing the Loop with Or- 
pheus 

Although the tools outlined above allow the 
translation of high-level artifacts to HDL, and 
while such a process supports methodology 
changes that could reduce design errors, there 
are problems with using these tools for flight 
critical applications. First, the process out- 
lined above requires that device development 
be accomplished by constructing a model or 
specification in formal logic. This is impracti- 
cal, as hardware development is most appro- 
priately done in an HDL or, in the case of 
hardware/software codesign, in an HLL. 

The second issue is tracibility. Specifically, 
there must be a way to trace the requirements 
to the device through the tools. This issue is 
analogous to the one discussed in Section 1.2 
that has until recently bedeviled those who 
wished to use an HDL for flight critical hard- 
ware design. Note that, unlike the fabrica- 
tion tools of Figure 1, the compilation tools 
described in Figure 5 are not arranged to be 
self-checking. As a result the two compilers 
employed in this process would have to be 
thoroughly vetted before they could be used 
in a process for developing flight critical de- 
vices, which is problematic. 

The Orpheus system addresses these two 
important issues by adding to the chain an- 


other tool, a model-generator, that converts an 
HDL design into a formal model. Figure 6 
shows how the Orpheus tools are arranged. 
The translators form a circle in which a rep- 
resentation is converted in turn into each of 
the other representations and ultimately back 
into its original representation language. For 
example, a device model could be developed in 
an HDL that supports fabrication. The model- 
generator then creates a formal model that can 
be analyzed using a theorem prover. Using 
executable formal models techniques, the for- 
mal model is translated into an HLL model 
that supports high-speed simulation. Finally, 
the HLL model is translated back into HDL, 
and shown to be equivalent to the initial HDL 
model using an equivalency checker of the kind 
used in the HDL fabrication process. 

There is only a single model, yet three 
distinct device representations are involved 
to support the three different uses: fabrica- 
tion, high-speed simulation, and formal analy- 
sis. These three activities support each other, 
both for model validation and in the fabrica- 
tion/verification process, because they involve 
the single model in different ways. 

As previously discussed, although the nec- 
essary formats can be generated without com- 
pleting the circle of translations, the question 
of translation correctness remains open. The 
certification of flight critical devices must ad- 
dress this issue. If the circle is completed, and 
the initial design and final design are shown 
equivalent, then each representation of the de- 
sign is guaranteed correct so long as at most 
one of the tools has erred. Much as the fab- 
rication tools diagrammed in Figure 1 are ar- 
ranged to be self-checking, so too are the Or- 
pheus translation tools. Even if more than one 
tool errs, the probability of catching the error 
is still very high since otherwise the multiple 
mistaken tools would have to fail in ways that 
mask each other’s errors. 

This kind of self-checking tool arrangement 



provides a very strong argument for the ab- 
sence of translator-induced errors, and makes 
this kind of development practical just as mod- 
ern self-checking fabrication tools permit HDL 
use in safety-critical devices. Orpheus there- 
fore provides a framework for tight and highly 
reliable integration of formal analysis, simula- 
tion, and fabrication. 

3.4 Orpheus Translation Circle 
Example 

To assess the technical feasibility of the Or- 
pheus approach, we have done a small exper- 
iment with using current versions of Orpheus 
components in a manner consistent with the 
tool arrangement of Figure 6. 

As discussed previously, one of the advan- 
tages of Orpheus is that it allows a developer 
to use any of the representations for his de- 
vice. We might expect VHDL to be the lan- 
guage of choice for hardware designers, while C 
might be preferred for hardware/software co- 
design. This experiment begins from a formal 
ACL2 model of an interrupt controller that 
forms part of a proprietary device developed 
by Rockwell Collins. We will navigate around 
the Orpheus circle to generate a. simulation 
model, a VHDL model, and a second formal 
model. We have already discussed the benefits 
accruing from these different representations. 
The point of the experiment is to observe that 
the two formal models have sufficient similari- 
ties in structure, complexity, and level of detail 
to indicate that a proof of their equivalence — 
and therefore a self-check of all the transla- 
tions — is feasible. 

The Common Lisp model of this device 
uses a macro package developed by Rockwell 
Collins to ease modeling in Common Lisp. 
The line 

(ST. SYNCl = (6 (ST. SYMCO) (HxFFDF) )) 


expresses the following behavioral detail: 
SYNCl is an element of the machine state, 
a register. It is updated each clock tick with 
the result of applying a constant bit-mask to 
another state variable, SYNCO. 

We also wish to simulate this device. We 
might choose merely to execute the Common 
Lisp code. However, there would be two dis- 
advantages to that approach. First, it would 
be slow. Our experiments with running ap- 
plicative Common Lisp models indicates that 
these models execute roughly 100 times slower 
than equivalent C language models [18]. Sec- 
ond, it is difficult to integrate raw, applicative 
Common Lisp into other tools. 

Rockwell Collins has been working on this 
challenge for two years and, as described 
above, has sped applicative Common Lisp ex- 
ecution and integrated this code into other ap- 
plications. This approach, broadly called “ex- 
ecutable formal models,” is outlined in two 
recent publications [10, 18]. Using these op- 
timizations and a Lisp compiler, we gener- 
ate a C program that executes at roughly the 
same speed as hand-coded C, and can be inte- 
grated with other software. Rockwell Collins 
in the past has integrated code of this type 
into various simulation and development envi- 
ronments [18]. 

We apply this technique to the example 
above. The line of the resulting C code that 
corresponds to the given line of Common Lisp 
reads as follows: 

V12= (D. SYNCl = ((((((Vll)), Q. SYNCO)) & 

( (- (33) )))),( (Vll) ) ) ; 

We also wish to fabricate this device. To 
do so we have applied a C-to-HDL tool (devel- 
oped by C level) to convert the auto-generated 
C program produced into VHDL. Many trans- 
formations are done, such as converting vari- 
ables in the C code that maintain state into 
registers in the VHDL. The line of C code 



shown above translates into the following line 
of VHDL: 

D_var ( SYNC 1_ 2’ range) := (Q_var (SYNC0_2 ’range) 

and "1111111111011111"); 

Ultimately, we wish to fabricate devices 
from VHDL using the approach outlined in 
Figure 1. We applied a Synopsys VHDL syn- 
thesizer to this VHDL code, and the result ap- 
pears correct. As described in Section 1.2, it is 
this synthesis step from VHDL that current- 
available tools such as the Chrysalis equiva- 
lence checker can verify. 

We really want to check much more than 
this final step. We want to verify that the syn- 
thesized design implements the formal model 
with which we began, so we complete the cir- 
cle with a model-generator developed by ORA 
[2, 3]. This tool currently generates a de- 
scription in first-order logic, rather than ACL2 
code, and there are other modest problems 
related to differences between the VHDL li- 
braries assumed by the C level tool and the 
libraries assumed by the ORA tool. How- 
ever, with minor manual changes to the VHDL 
needed to overcome the library issue, we were 
able to use the model-generator to construct a 
specification in first-order logic. In this nota- 
tion, the value assigned to SYNC1 is: 

(slice(s.q, 79, 64) and 

flip (shift (vector ("1111111111011111"), 78)))) 

The “slice” expression denotes the 16-bit 
slice of vector q that, by definition, represents 
SYNCO. The “flip” expression is of course the 
mask. (It is “flipped” because q has been de- 
fined to run down from 79 to 64 rather than 
up from 64 to 79.) Although it is expressed 
in a different syntax (i.e. Larch/ VHDL rather 
than ACL2) the generated formal model corre- 
sponds term-by-term to the original Common 
Lisp (ACL2) model. 

Sophisticated digital design, simulation and 
test-generation, and machine-checked formal 
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Figure 7: Orpheus Supports and Integrates 
Each Design Activity 


analysis, each individually pose technical chal- 
lenges that are not solved by using the Or- 
pheus approach. However, Orpheus provides 
a framework for integrating these separate do- 
mains, and we believe that the simple exper- 
iment reported here indicates that this novel 
technical approach can succeed. 


4 Summary 

Current verification and certification of de- 
vices appears increasingly inadequate in the 
face of increasing complexity of flight critical 
systems. Figure 7 summarizes the Orpheus 
approach. Orpheus supports hardware de- 
velopment and hard ware/ soft ware codevelop- 
ment in a way that allows for formal analysis, 
fabrication, and high-speed simulation. The 
Orpheus tools are self-checking, just as mod- 
ern HDL fabrication tools are, to insure their 
reliability. Orpheus supports a verification ap- 
proach that forms the basis of a superior certi- 
fication approach that provides a way to meet 
this looming challenge. 
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Abstract 

This paper describes an integrated design methodology for the use of formal methods with existing tools in the 
context of developing FonnalCORE PCI/32. The primary goal is to develop technology for the design and 
verification of formally verified IP cores that includes all the features, documentation, and support necessary to 
insure integration into designs with the high degree of reliability provided by the application of formal 
methods. Validation techniques used in developing these cores include formal specification, formal synthesis, 
simulation, hardware emulation, theorem proving, and model checking. 

1 Introduction 

The PCI[6,7] Local Bus is a high performance, 32-bit or 64-bit bus with multiplexed address and data lines. 
The bus is designed for use as a high-speed interconnect mechanism between peripheral components and 
processor/memory subsystems. 

FonnalCORE™ PCI/32 is a synthesizable VHDL[4] 32-bit, 33MHz PCI interface core targeted to 
programmable hardware. The VHDL description is formally synthesized using our DRS[1,2] formal synthesis 
system and fonnally verified using the Verysys PropertyProver model checker to be compliant with the v2.1 
PCI specification. 

The overall goal of the project is increased assurance by using a variety of fonnal methods technologies in 
concert to attack a practical problem. We have developed the methodology for the design and validation of 
VHDL cores with a variety of tools that can serve as documentation, and increase assurance. In meeting the 
primary goal of the project we achieve a reduction in the development time as well. Once the design flow was 
in place, correcting specification bugs and rechecking the properties was a routine task rather than a challenge. 

A key benefit to this approach is that it allows for the deployment of fonnal methods into current engineering 
practice via pre -designed, pre -verified components that meet the stringent reliability and safety requirements 
that are necessary in avionics and space applications. These components can then be integrated into larger 
designs providing the building blocks for complex designs and the foundation for design reuse. 

In developing the FormalCORE technology we rely heavily on both fonnal and traditional design and 
verification tools. We recognize at the early stages of planning that a comprehensive approach to the 
integration of fonnal verification techniques to an existing design flow is critical to the success of the 
technology. A well implemented design and verification strategy, incorporating fonnal techniques at key 
points in the design flow minimizes the likelihood of design errors. 

2 The PCI Bus Protocol Standard Revision 2.1 

The PCI bus specification was first developed by Intel Corporation and was released in June 1992. It was 
intended to define an industry standard for local bus architectures. Revision 2.1 became available in early 
1995 and is managed by a consortium of industry partners known as the PCI Special hiterest Group. The 
specification is a 282-page English language document describing the protocol, electrical, mechanical, and 
configuration specification for PCI components and expansion boards. 



The PCI specification defines two possible PCI agents, a master and a target. The master is the device that 
mitiates a transfer. The target is the device currently addressed by the master for the purpose of performing a 
data transfer. The master and target state machines are independent. However, a master device must 
incorporate a target device for the purpose of responding to system configuration requests. 

The minimum PCI compliant device satisfies the requirements of a target-only device. This device requires 47 
pins and can only respond to a master initiated transaction. A master device requires two additional signals, 
(REQ# and GNT#), for it to handle data and addressing, interface control, arbitration, and system functions. 
Figure 1 illustrates the required and optional signals for a PCI compliant device. The signals on the left are 
required pins for target and master devices. The signals on the right are optional pins and are used to support 
the 64-bit extension to the specification, exclusive access (LOCK#), interrupts, cache support, and the JTAG 
(EEEE 1149.1) boundary scan interface. 
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Figure 1 : PCI Compliant Device Signals 

The heart of the PCI Bus Protocol is the burst transfer mechanism. A burst transfer consists of a single address 
phase followed by two or more data phases. The start address and transaction type are issued during the 
address phase. The target device latches the start address into an address counter and is responsible for 
incrementing the address from data phase to data phase. Figure 2 illustrates a sample read transaction. 


A basic bus cycle involves the FRAME#, FRDY#, TRDY#, C/BE# control signals as well as the multiplexed 
address/data AD[31:0] lines and the parity signal PAR and DEVSEL#. The bus cycle starts with an address 
phase. This is the first clock after FRAME# is asserted by the master. During this cycle, the address lines 
carry the desired address and the C/BE# signals the bus command. Bus commands encode the address space 
and direction of transfer. There are also some special bus cycles, like interrupt acknowledge and various 
memory transfer modes. After the address phase, the master goes into the data phase. 


The addressed target, will then decode the address to determine if it needs to take the bus cycle. It can decode 
either as a fast/medium/slow decoder, which are 1,2,3 cycles after the address phase. Once it has decoded and 
accepted the bus cycle, it asserts the DEVSEL# signal to signal that it will take the bus cycle. When the master 
has sent data via the AD[31:0] or when it is ready to receive data, it will assert the FRDY# signal. The target 
indicates its readiness with the TRDY# signal. Only when the TRDY# and FRDY# signals are both asserted, 
will a data transfer take place. Otherwise wait states are inserted. The master controls how much data is 
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Figure 2: PCI Timing Diagram 


transferred. When it is done transferring data, it will de -assert FRAME# on the last data phase. When the 
target sees neither FRAME# or IRDY#, the master has finished. 

The target uses the STOP# signal to signal the master that it has to terminate the current transaction. The PCI 
Target asserts combinations of TRDY#, DEVSEL#, and STOP# to signal different termination conditions. 
The PCI protocol is specified in plain English. The specification contains rules such as: 

“Data is transferred when IRDY # and TRDY # are asserted.” 

“When either TRDY# or IRDY# is deasserted, a wait cycle is inserted arid no data is transferred.” 

3 FormalCORE PCI/32 - A Formally Verified PCI Interface 



Figure 3: FormalCORE PCI/32 System Architecture 





FormalCORE PCI/32 is a synthesizable VHDL 32-bit, 33 MHz PCI interface targeted to programmable 
hardware, fonnally verified to be compliant with the v2.1 PCI specification. Figure 3 is a block diagram of the 
FormalCORE PCI/32 system architecture. 

The design is composed of three primary modules. A PCI Interface Module, Decoder/Device Configuration 
Module, and PCI Application Module. The PCI Interface Module is the primary interface to the PCI bus and 
user application. It contains the Target and Master state machines, parity circuit, and implements the bus 
protocol. The Decoder/Device Configuration Module contains the PCI configuration registers and address 
decode circuitry. The PCI Application Module is a stub module defining a backend interface. This module is 
used to integrate the user's application into the PCI core. It is not specified in v2.1 since it is dependent on the 
specific device. For example, the Application Interface would vary widely between a video device and a 
modem. This partitioning allows us to swap different application backends to the existing core with minor 
modifications. 


4 Design and Verification Tools 

The software tools comprising our design and verification suite included: 

• DRS (Derivational Reasoning System), fonnal synthesis system from Derivation Systems, Inc. to develop 
high-level formal behavioral specification, high-level simulation, hardware emulation, and formal 
synthesis to VHDL and gate-level netlist. We use DRS to derive a structural specification from the top- 
level behavioral description, synthesize VHDL code and PVS theories. The system was also used for 
functional simulation of the top-level specification, and as the interface to hardware emulation of the 
synthesized design. 

• PVS[5] (Prototype Verification System) from SRI for validating safety and liveness properties of the top- 
level behavior specification. 

• Verysys PropertyProver[8] and StructureProver[8], PropertyProver is a state-of-the-art model checker that 
can verify model properties at the Behavior, RTL and Gate levels. StructureProver is a high-perfonnance, 
high capacity equivalence checking tool that can be used at the RTL and Gate levels. The Verysys tool 
suite was chosen for its support of the IEEE 1076 VHDL standard and hierarchical verification. In 
addition, PropertyProver generates an input sequence and a VHDL testbench for counter-examples. The 
built in VHDL simulator can be used to simulate the counter example. 

• Verysys Circuit hiterface Language[3,8] to formally describe circuit properties. These properties are 
described using temporal relationships between the various input and output ports of the circuit. CEL is 
used to describe the PCI Compliance Model to validate the VHDL core. Properties are written in an 
assumption-commitment style. Predicates in the logic are written using VHDL syntax. 

• ModelSim from Model Technologies for VHDL simulation. ModelSim is chosen because it is a full 
featured VHDL simulator providing accurate modeling of the language. It provides a rich set of features. 

• Xilinx Foundation Express[9] for VHDL synthesis, gate-level tuning analysis, gate -level simulation, and 
FPGA programming. Foundation Express incorporates the Synopsys Express VHDL compiler and Aldec 
gate-level timing analyzer and simulator. Foundation Express provides a low-cost, comprehensive 
solution for FPGA programming. The entry to the tool can be VHDL, Verilog, Schematic entry, or gate- 
level netlist. Xilinx offers a variety of chips that are PCI compatible and is an industry leader in 
programmable hardware. 



5 Design and Verification 


The primary design criteria for FonnalCORE PCI/32 was to synthesize a VHDL model from DRS that would 
run at 33Mhz, optimized for size, and compatible with the various VHDL level tools. The generated VHDL 
had to be compatible with the Verysys model checker, Synopsys FPGA Express compiler, and Model 
Technologies VHDL simulator. 

From the PCI Specification document, we developed a formal PCI compliance model in CEL, Verysys circuit 
interface language. These properties are described using temporal relationships between the various input and 
output ports of the circuit. They are extracted from the PCI mles in the specification document. 

Formal design and verification is a theme that runs throughout the lifecycle of the FormalCORE PCI/32 
development. Verification tools were used continuously once the design reached a state where the tools were 
applicable. DRS synthesis served as a backplane for the design flow. Changes in the design were reflected in 
the DRS top-level specification and the VHDL was re-synthesized. 

The need for verification in this project was two fold. First the specification had to be proven to meet the PCI 
specification properties. The correctness of the specification in derivation is assumed, not proven. Secondly, 
even though DRS guarantees correctness of its transformations in the original specification, the state 
representation and the VHDL translation are not reasoned about. Therefore, the generated VHDL had to be 
shown to satisfy the same properties as the initial DRS specification. 

Once a stable DRS specification was established, PVS was employed to validate the DRS top-level 
description. DRS was then used to derive a structural description from the top-level specification and generate 
VHDL. Verysys model checker, Model Technologies VHDL simulator, and Synopsis VHDL compiler were 
used for VHDL property verification, simulation and synthesis. The synthesized gate-level design was 
simulated with the Xilinx simulator. 

Several modes of validation were always running in parallel. We performed functional simulation of the top- 
level and structural DRS descriptions. We simulated the design both at the VHDL and gate-level. Formal 
verification at the high-level, and fonnal verification at the VHDL level were used to validate properties of the 
design. The design flow (Figure 4), from high-level fonnal specification to running hardware can be 
characterized as five stages of design. 



Figure 4: Design Flow 

The design flow reflects a top-down design methodology. It provides for the fonnal specification and 
verification at an abstract behavioral level, and a systematic process to refute the design to a concrete VHDL 
implementation. Tire design flow incorporates formal and traditional validation techniques. The use of DRS 








and formal methods contributes to the soundness of the specification and implementation, and VHDL provides 
an industry standard language to interface to other tools. Figure 5 details the design and verification flow and 
the tools used. Shaded boxes denote fonnal tools. Shaded ovals denote fonnal specifications. Clear boxes 
denote traditional design tools. 



5.1 Specification Development 

In the first stage the top-level behavior specification is developed and validated using simulation and formal 
verification. Verification begins early using the DRS functional simulator. A high-level behavioral model is 
written in DRS and ran against test vectors. This behavior model becomes the reference model for all 
subsequent verification and synthesis. 

[b_busy 

(lambda (add_reg cbe_reg idsel_reg . . . ) 

(let ( fdevsel_lo_o HI] [serr_lo_o HI] [trdy_lo_o HI] 

[stop_lo_o (not (and (or t_abort term) 
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• • • ) 
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(s_data . . . ) 

...))))] 


Figure 6: Code fragment for Target Interface b busy state 





















The top-level DRS specification is a collection of communicating state machines. Each state machine is 
defined in tenns of a set of mutually recursive function definitions. A fragment of the b_busy state of the 
Target Interface is depicted in Figure 6. Because of the reactive nature of the protocol specifications, the 
specification is written at a fine level of granularity. The specification captures the complete synchronous 
behavior of the PCI core circuit. 


DRS descriptions were written for the master and target state machines along with their lock machines, the 
configuration/decode circuit, the parity circuit, and a basic application backend. The chip-level glue-logic was 
also written integrating all the modules into a single core. Figure 7 illustrates the modules and their 
interconnectivity. 



Figure 7 : DRS Specification Hierarchy 

An abbreviated form of the top-level DRS description is shown below. The module instantiations are show in 
bold. 

(define mchip 

(lambda (cbe_lo ad par idsel frame_lo irdy_lo trdy_lo stop_lo lock_lo 
perr_lo serr_lo devsel_lo gnt_lo) 

( stream-let rec 

( [tsbuf (lambda (o oe) (if oe o #\z))] 

[parity (lambda ( (dO . . . d31) (cO cl c2 c3) ) (b-xor ...))] 

. . . ) 

(letrec (...) ; ; -- Component descriptions 

( system- let rec 

( [ (add_reg cbe_reg idsel_reg . . . ) (target_xf ace ad cbe_lo par . . . ) ] 

[ (conf_data hit d_done cfcmd . . . ) (target_conf add_reg ad . . . ) ] 

[ (ad_o cbe_lo_o tstatus t_abort . . . ) (backend mxfer add_reg . . . ) ] 

[ (lock_lo_oe own_lock . . . ) (master_xf ace par idsel frame_lo . . . ) ] 

[ (tfree tlocked) (target_lock frame_lo lock_lo l_lock_lo hit . . . ) ] 

[ (lock_free) (master_lock frame_lo lock_lo own_lock) ] 

[par c (parity (if par dir ad out ad) 

(if par dir cbe lo out cbe lo) ) ] 

[ad out (tsbuf32 (if (b-or ior cmdwr) ad o conf data) 

(b-or ad oe m ad oe) ) ] 

[frame lo out (tsbuf frame lo o frame lo oe)] 

[irdy lo out (tsbuf irdy lo o irdy lo oe) ] 

• • • ) 

(list ad out cbe lo out par out frame lo out trdy lo out irdy lo out 
stop lo out perr lo out serr lo out devsel lo out req lo 
lock lo out ...)))))) 




The DRS behavior model is automatically translated into a PVS theory to perform fonnal verification. The 
primary goal is to verify that the specification satisfies a set of high-level safety and liveness properties. 
Inconsistencies in the top-level specification found by PVS are then manually corrected in the DRS 
specification. 

The DRS->PVS translator generates a PVS function corresponding to the state to state transition of the DRS 
model. PVS was used to analyze the functional properties of the specification. For example, we show that the 
trdy_lo_o signal is asserted only when t_abort is false and ready is true with the PVS theorem: 

trdy_on_write : THEOREM 

(FORALL (t abort: bit, tar dly : bit, ready: bit) : 

compute trdy lo (write, t abort, tar dly, ready) = true lo 
IFF NOT(t_abort) AND ready) . “ 

The From_idle_goto_busy theorem states that from IDLE, only when frame_lo_i is asserted, the 
Target sequencer goes to the BUS BUSY state. 

From_idle_goto_busy : THEOREM 

(FORALL ( ( f rame_lo_i : bit), (irdy_lo_i : bit), (trdy_lo_i : bit), 
(stop_lo_i: bit), (perr_lo_i : bit), (serr_lo_i: bit), 

( devsel_lo_i : bit), (ready: bit), (t_abort : bit), 

(term: bit), (state: state_type) , 

(cbe_reg: [bit, bit, bit, bit]), (tar_dly: bit), 

(par_dat : bit), (par_en: bit), (par_i : bit), 

(perr_dat : bit), (r_perr: bit), (rperr_reg: bit)) : 
idle (frame_lo__i, irdy_lo_i, trdy_lo_i, stop_lo_i, 
perr_lo__i, serr^lo^i, devsel_lo_i, ready, 
t_abort, term, state, cbe_reg, tar_dly, par_dat, 
parpen, par_i, perr_dat, r_perr, rperr^reg) 

= bus_busy 

IFF (frame_lo_i = true_lo) ) 

Many of the functional properties verified in PVS were also verified in the Verysys model checker. Both PVS 
and Verysys were useful in finding errors in the design. Early in the design process, we used sample equations 
from the PCI specification as a guide to developing the DRS specification. PVS uncovered overlaps in some 
of the equations. A set of conditions would satisfy two different equations. 


5.2 Formal Synthesis using DRS 

In the second stage, fonnal synthesis is used to manipulate the design hierarchy and derive a VHDL 
description from the top-level behavior specification. This process requires manual guidance from the 
designer. DRS provides automated support for transfonning the specification to a concrete implementation, 
however, design decisions are made by the designer. DRS maintains correctness and does not allow the 
introduction of errors. The key benefit is that it provides the designer with direct control over the synthesis 
process. 

DRS can manipulate a large class of designs including datapath and/or control oriented circuits. The PCI 
specification is a control-dominated circuit geared for bus protocol. DRS allowed us to manipulate the PCI 
design hierarchy providing a means of managing the complexity of the verification and defining the 
synthesized VHDL modules. We found that manipulating the design hierarchy of the VHDL would impact 
how the VHDL compiler would synthesize the design. Hierarchy played an important role in the speed of the 
synthesized circuit. The synthesizer did better when the design was in logically organized major blocks than a 
totally flat description or when there were many small modules instantiated in the larger ones. 



The derivation was limited to obtaining a structural specification and generating the support modules from 
DRS libraries. We added four valued logic libraries to DRS. This enabled DRS to generate tristated 
input/output signals which are essential in a bus implementation. 

The following table summaries the number of derivation steps, the specification and implementation size for 
each of the modules, along with the top-level mchip module. 
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Backend 

Txface 
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Tlock 

Lock 
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DervSteps 

14 

14 

15 
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77 

30 

19 

9 

55 

Spec Size 

899 
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4440 

12800 

13906 

5507 

732 

347 

6209 

Imp. Size 

3194 

3434 

14286 
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7471 

10632 
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416 

55790 

VHDL Size 

2669 

2849 

11909 

11832 

8425 

8792 

1002 

858 

48973 

VHDL Comp 

2669 

2849 

5493 

9163 

8425 

8792 

1002 
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9722 


DRS and VHDL sizes include all the modules that make up the component. The component VHDL size lists 
only the size of that component. All sizes in bytes. 


5.3 VHDL Generation, Validation and Synthesis 

5.3.1 VHDL Generation 

Once the design is refined to a concrete architecture in DRS, VHDL files are automatically generated and the 
VHDL Validation and Synthesis process begins. Model Technologies ModelSIM is used to simulate the 
VHDL. To streamline our simulation environment, we created interfaces from the DRS simulator to the 
VHDL and netlist simulator. This provided us the ability to localize our test vector generation within the DRS 
framework, and then automatically generate test vectors to validate the netlist generated by the VHDL 
compiler, and VHDL simulator. 

The tools we used understood only a restricted subset of the VHDL language. We had to tune the VHDL 
generation toward the common syntax used among these tools. For example, the Verysys VHDL type checker 
could not resolve predicates of the fonn: ad ( 1 : 0 ) = "00". 'Hie DRS VHDL generation had to produce 
expressions of the form: ad ( 1 ) = 'O’ and ad ( 0 ) = 'O'. 

The VHDL compiler infers registers in a design depending on the way the code is written. Rather than an 
implicit mechanism to infer registers, we controlled the introduction of registers hi the design by an explicit 
register entity, that served as a state holding abstraction and directly corresponded to DRS registers. The 
combinational logic is expressed as simple equations of assignments and entity instantiation. The resulting 
VHDL follows the intended implementation architecture closely. 

To improve performance we experimented with several hierarchical design layouts. When flattening 
hierarchies the circuits were logically equivalent. However the circuit speed varied widely. 

In generating VHDL, DRS constructs had to be mapped carefully over to VHDL constructs to ensure the 
semantics of the DRS expression is maintained. One problem we ran into was generating VHDL code for 
nested DRS if-then-else expressions. These expressions cannot be converted to selected signal assignments 
(WITH statement) unless the else branch guard is ANDed with the negated test expression. However, 
conditional signal assignment behaves just like a nested DRS if-then-else expression and is used instead of the 
WITH statement, hi fact, the Verysys model checker uncovered this bug in the DRS VHDL generation. 



5.3.2 VHDL Validation 


The Verysys model checker is used to validate the VHDL against the PCI compliance model written in CEL. 
The underlying model checking technology used by the Verysys tools is the Siemens Circuit Verification 
Environment (CVE) [3], The system is a BDD based symbolic model checker. It supports EDLF and VHDL, 
and generates VHDL test benches for counter examples. 

Circuit properties are written in CEL (Circuit interval Language). CEL formulae are built up from timed 
predicates that consist of a state predicate and a temporal specification. The temporal specification describes 
when the machine should be in a state that satisfies the state predicate. The state predicate is given in the 
subset of Boolean expressions in VHDL. The temporal specifications refer either to a particular point of time, 
or to a whole period. A point of time is specified after the keyword at. A period is specified by an interval, 
which is a uniform representation of three different types: [tl, t2] , refers to the time between tl and t2 
inclusively, [tl, infinite] , refers to t and every point after t, [t, p] , refers to the time between t 
and the last point of tune before the state predicate p is satisfied for the next time. 

An interval is preceded by during or within to specify whether the state predicate holds during the whole 
period or at least once in the interval. Times are either integer constants or defined relative to a variable t 
which is universally or existentially quantified by always and finally. 

As an example, we express the property that the "Target Sequencer will never deadlock" as: 

theorem target_d.ead.lock; 

assume: (set = 'O' during [0, infinite]); 

prove: always (possibly state = idle within [t, infinite]); 
end theorem; 

The assumption eliminates the reset state, and the proof guarantees that no matter what state the Target 
Sequencer is in, there exists a path to the idle state. 

We prove that the Target Sequencer that implements the sustained tristate signals correctly with the following 
theorem: 

theorem target_sustained_t ristate_trdy ; 

assume: (set = 'O' during [0, infinite]); 

prove: always ( (trdy_lo_oe = '1' at t-1) and 
(trdy_lo_oe = 'O' at t) 

implies (trdy_lo_o = '1' at t-1)); 

end theorem; 

In order for a signal to adhere to the sustained tristate property, it must drive the signal high one clock cycle 
before tristating the signal. 

Most of the effort at this stage was spent developing the PCI compliance model. It was critical to be able to 
ask the "right" question. This was difficult since we had no prior understanding of the PCI protocol. Once the 
protocol was understood, writing the CEL properties from the PCI specification was fairly straight forward and 
the actual running of the model checker was automatic. Counter examples generated by the model checker 
were validated with the ModelSIM simulator at the VHDL level as well as in the DRS simulator. This 
capability allowed us to pinpoint if the problem was in the top-level DRS specification, VHDL generation, or 
VHDL code. 

The design environment of this project consisted of two dynamic aspects: on the one hand the engineering 
process and on the other the formal process. From initial specification to working hardware the model checker 
did not find any errors that our hardware engineer did not find using traditional techniques. The model 



checking was lagging behind in this process. Errors uncovered by the engineering process led to revisions in 
the DRS specification. 


After working hardware was achieved the model checker started finding errors in the design that the simulator 
did not uncover. This was due to three facts. First, the simulation tests were not exhaustive. Second, 
hardware and specification reached a level of maturity where the core appeared to work for most cases. 
Thirdly, we developed a better understanding of the PCI protocol. 

The compliance model provides a comprehensive formal validation of PCI compliance and becomes extremely 
valuable in providing exhaustive analysis of the VHDL model. Inconsistencies found in the PCI specification 
were documented, and design decisions were made to resolve them. 

5.3.3 VHDL Synthesis 

The VHDL files are input to Synopsys LPGA Express compiler for netlist synthesis. The issue in this process 
is that minor changes to the VHDL would result in significant performance changes in the synthesized netlist. 


5.4 Netlist Validation and Mapping 

The next stage involves simulating the netlist, and using the model checker to validate that the VHDL 
synthesis has not introduced any errors. Timing analysis is also done at this tune. The netlist is then mapped 
to the appropriate target technology for hardware programming. At this stage, the logic netlist is validated 
using the Aldec netlist simulator. Test vectors written for the DRS architectural simulation are used at the 
VHDL and netlist level. 

The logic netlist is formally verified using Verysys StructureProver. This ensures that the synthesized netlist 
behaves identical to the VHDL model in order to eliminate the possibility that logic bugs that would be 
introduced during VHDL synthesis. The equivalence checker compares the finite state mach in e models of the 
VHDL source and EDIF files of the synthesized netlist. There were no errors in the VHDL synthesis. 

The Xilinx mapper then synthesized the appropriate configuration files for the target device. 


5.5 Post-design Validation 

Traditional hardware techniques were used for post-design validation. 

The DRS Functional Test Environment (FTE) was used for hardware emulation of the synthesized PCI core. 
The FTE consists of the DRS simulation environment communicating with a Ampro EBX fonn factor Pentium 
based single board computer (SBC) and the PF2000 PC/104 LPGA module. The synthesized core is 
downloaded on to the PF2000 LPGA module. Then the DRS simulator drives the inputs of the circuit, single 
steps the clock, and samples the outputs, displaying them in the DRS simulator, hi contrast to the functional 
simulation of the model in DRS, the FTE was used to compare the functional behavior of the model to that of 
a design that has been processed by implementation specific back end tools. 

The core has been targeted to Xilinx XC4000 and Virtex family of FPGA devices. A working prototype is 
running in two different environments. The first system is a standard PCI/ISAbus AT motherboard with a 
AMD-K5 processor clocked at 133MHz. It includes an NE2000 compatible ISAbus based Ethernet card and a 
PCI VGA card.. The second system is an AMPRO PC/1 04+ system consisting of a Ampro EBX fonn factor 
Pentium based single board computer (SBC). Both systems are configured with 32Mb of memory and runs 
Linux RedHat 6.0, which is based on a 2.2.5 Linux kernel. 



6 Conclusions 


The methodology developed to build the FonnalCORE PCI/32 is an example of how formal tools and 
traditional simulation and synthesis tools are integrated for the design and validation of VHDL IP cores. These 
cores can then be integrated into larger designs providing the building blocks for complex designs. 

The FonnalCORE PCI/32 and associated PCI compliance model consists of pre-designed, pre -verified VHDL 
components that can be integrated into larger designs and a validation suite providing exhaustive analysis of 
the VHDL models using a commercial model checker. The core has been designed to be flexible and can be 
adapted to a variety of designs with little or no modification to the VHDL or compliance model. 

One observation is in the early stages of this project, traditional techniques led the design process. The 
Models IM VHDL simulator, Aldec netlist simulator, and hardware Logic Analyzer were used to debug the 
design. The model checker did not find any errors that either simulation or hardware debugging did not catch. 
The traditional techniques were satisfactory in achieving a working prototype. In the later stages of the 
project, the formal techniques led the design process. The model checker was able to find errors in the design 
that were not tested for in simulation. Using the DRS system, we were able to routinely make changes to the 
top-level specification, manipulate the design hierarchy, and re-synthesize the VHDL core. We could then re- 
validate the core against the compliance model automatically. 

Both PVS and the Verysys model checker were useful in developing the PCI core. PVS was used to verify 
functional properties of the DRS top-level specification. Verysys was used to verify functional and temporal 
properties of the DRS generated VHDL. The Verysys verification effort was more extensive since the end 
goal was to develop a verified VHDL PCI core and compliance model. 

This work has significantly enhanced our capability to design and validate VHDL cores. The enhancements 
added to the DRS system are general and can be used to synthesize a wide array of designs. 

The future work on this topic is to extend the PCI core and Compliance model to the 64-bit PCI standard, 
retarget the core to operate at 66Mhz, and update the design to Revision 2.2 of 

the PCI specification, hr addition, we would like to perform an independent validation of the compliance 
properties. 
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Abstract 

Formal capture and analysis of the required behav- 
ior of control systems have many advantages. For in- 
stance, it encourages rigorous requirements analysis, 
the required behavior is unambiguously defined, and 
we can assure that various safety properties are satis- 
fied. Formal modeling is, however, a costly and time 
consuming process and if one could reuse the formal 
models over a family of products, significant cost sav- 
ings would be realized. 

In an ongoing project we are investigating how to 
structure state-based models to achieve a high level 
of reusability within product families. In this paper 
we discuss a high-level structure of requirements mod- 
els that achieves reusability of the desired control be- 
havior across varying hardware platforms in a prod- 
uct family. The structuring approach is demonstrated 
through a case study in the mobile robotics domain 
where the desired robot behavior is reused on two di- 
verse platforms — one commercial mobile platform and 
one build in-house. We use our language RSML ~ e to 
capture the control behavior for reuse and our tool 
NIMBUS to demonstrate how the formal specification 
can be validated and used as a prototype on the two 
platforms. 

Keywords: Requirements, Formal Models, Re- 
quirements Reuse, Control Systems, RSML _e 
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1 Introduction 

Reuse of software engineering artifacts across 
projects has the potential to provide lar ge cost savings. 
Traditionally, the research in the reuse community has 
focused on how to construct reusable software com- 
ponents, and how to classify and organize these com- 
ponents into libraries where they can be retrieved for 
use in a particular application. We know, however, that 
coding errors are not the main source of problems and 
delays in a software project; incomplete, inconsistent, 
incorrect, and poorly validated requirements are the 
primary culprit [4], Tlius, we hypothesize that reuse 
of requirements in conjunction with reuse of design 
and code will provide greater benefits in terms of both 
cost and quality, hi this paper we present an approach 
to structuring formal requirements models for control 
systems that make the control requirements reusable 
across platforms where the hardware (sensors and ac- 
tuators) may vary. We also illustrate the structuring 
approach with an example from the mobile robotics 
domain. 

The beginnings of our approach is a high-level re- 
quirements structuring technique based on the rela- 
tionship between system requirements and the soft- 
ware specification. We developed this structuring 
technique to enable a software development approach 
we call specification-based prototyping [23] where 
the formal requirements model is used as a prototype 
(possibly controlling the actual hardware — hardware - 
in-the-loop-simulation) during the early stages of a 
project. Here we present how this structuring ap- 
proach also enables reuse of the high-level require- 
ments across members of a product family with vari- 
abilities in the hardware components. The approach is 



demonstrated via a case study in the mobile robotics 
domain where the desired robot behavior is reused on 
two diverse platforms — one commercial mobile robot 
and one built in-house. We use our language RSML -e 
to capture the desired control behavior for reuse and 
our tool Nimbus to demonstrate how the formal spec- 
ification can be validated and used as a prototype on 
both platforms. 

The rest of the paper is organized as follows. Sec- 
tion 2 describes related work on requirements reuse 
and product families. Then, Section 3 describes our 
approach to structuring the high-level system require- 
ment and the software specification. Section 4 de- 
scribes the mobile robotics platforms that we are using 
as the case study in the paper and presents a simple 
analysis of their commonalities and variabilities. The 
requirements of the mobile platforms in the family are 
presented in Section 5. The refinement of these system 
requirements to a software specification is presented in 
Section 6. hr this section we also show how the sys- 
tem requirements at e reused across the members of the 
product family. Finally, Section 7 presents a summary 
and conclusion. 

2 Related Work 

Tire foundations for reuse of can be traced back to 
the early work on program structure and modularity 
pioneered by David Parnas and others [3, 20, 21, 22]. 
This work establishes the basis for reuse: the concept 
of a self contained module with well-defined inter- 
faces. Nevertheless, the guidelines for how to encap- 
sulate and structure a model (in this case implemen- 
tations) for reuse is not sufficiently addressed in this 
early work. Tlius, subsequent research in the field of 
software reuse seeks to further define and provide ad- 
ditional tools and techniques for reuse. 

In the area of requirements reuse, Lam et ai pro- 
vides some guidance on specific techniques which can 
be used by organizations to introduce requirements 
reuse into their software process [15]. In addition, 
Lam addressed requirements reuse in the context of 
component-based software engineering [14]. Our area 
of interest is more in structuring of specifications to 
achieve reuse; nevertheless, this work presents some 
ideas about how to package and specify generic re- 
quirements and how to factor requirements into plug- 
gable requirements parts [15], Of particular interest is 
the relationship of their work to the product families 
work being done at Lucent Technologies [2, 24], 

Product family engineering is related to the work 
presented in this paper; in particular, the FAST (Fam- 
ily Oriented Abstraction, Specification and Transla- 


tion) approach is of interest. FAST provides a pro- 
cess for how to identify commonalities and variabili- 
ties across a product family. This commonality analy- 
sis can then be used to provide domain specific devel- 
opment tools that will greatly reduce the development 
costs for later generations of the product family. FAST 
does not explicitly address the structuring of product 
requirements. The FAST concepts of the domain anal- 
ysis and the commonality analysis can, however, be di- 
rectly applied to our work with formal specifications; 
FAST provided some of the inspiration for the work 
presented here. 

Little work has been done on how to structure and 
develop a formal specification in a language such as 
RSML -e . One notable exception is the CoRE method- 
ology [5, 6, 7] developed by the Software Productivity 
Consortium. CoRE includes much useful information 
on how to perform requirements modeling in a semi- 
formal specification language (similar to the formal 
SCR defined at the Naval Research Laboratory [12]). 
Even so, the structuring mechanism proposed in the 
CoRE guidebook is based on the physical structure of 
the system as well as which pieces of the system that 
are likely to change together — these two (often con- 
flicting) structuring mechanisms may or may not be 
beneficial to reuse. Furthermore, the way in which 
the structuring techniques achieve reuse is not spec- 
ified in the guidebook — reuse is not specifically ad- 
dressed. Our work is based on many ideas similar to 
those found in CoRE, but we have extended and re- 
fined these ideas to address structuring of state-based 
requirements models to achieve (1) conceptual clar- 
ity, (2) robustness in the face of the inevitable require- 
ments changes to which every project is subjected, (3) 
robustness of the requirements as hardware evolves, 
and (4) reuse of models as well as V&V results. 

3 Structuring 

hr our work we are primary interested in safety crit- 
ical applications; that is, applications where malfunc- 
tion of the software may lead to death, injury, or en- 
vironmental damage. Most, if not all, such systems 
are some form of a process control system where the 
software is participating in the control of a physical 
system. 

3.1 Control Systems 

A general view of a software controlled system can 
be seen in the center of Figure 1 . This model con- 
sists of a process, sensors, actuators, and a software 
controller. The process is the physical process we are 
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function OUT maps OUTPUT to CON. The behavior 
of the software controller is defined by the SOFT rela- 
tion that maps INPUT to OUTPUT. 

The requirements on the control system are ex- 
pressed with the REQ relation; the system require- 
ments shall always be expressed in terms of quanti- 
ties in the physical world. To develop the control soft- 
ware, however, we are interested in the SOFT relation. 
Titus, we must somehow refine the system require- 
ments (the REQ relation) into the software specifica- 
tion (the SOFT relation). 

3.2 Structuring SOFT 


Figure 1. A traditional process control 
model (center) and how it is captured 
with the four variable model 


attempting to control. The sensors measure physical 
quantities in the process. These measurements are pro- 
vided as input to the software controller. The con- 
troller makes decisions on what actions are needed 
and commands the actuators to manipulate the pro- 
cess. The goal of the software control is to maintain 
some properties in the physical process. Thus, un- 
derstanding how the sensors, actuators, and process 
behave is essential for the development and evalua- 
tion of correct software. The importance of this sys- 
tems view has been repeatedly pointed out in the liter- 
ature [19, 17, 12], 

To reason about this type of software controlled 
systems, David Parnas and Jan Madey defined what 
they call the four-variable model (outside square of 
Figure 1) [19], In this model, the monitored vari- 
ables (MON) are physical quantities we measure in 
the system and controlled variables (CON) are phys- 
ical quantities we will control. The requirements on 
the control system are expressed as a mapping (REQ) 
from monitored to controlled variables. For instance, 
a requirement may be that “in case of a collision, the 
robot must back up and turn 90 degrees left’.’ Natu- 
rally, to implement the control software we must have 
sensors providing the software with measured values 
of the monitored variables (INPUT), for example, an 
indication if the robot has collided with an obstacle. 
The sensors transform MON to INPUT through the IN 
relation; thus, the IN relation defines the sensor func- 
tions. To adjust the controlled variables, the software 
generates output that activates various actuators that 
can manipulate the physical process, for instance, a 
means to vary the speed of the robot. The actuator 


The IN and OUT relations are determined by the 
sensors and actuators used in the system. For example, 
to determine if the robot has collided with an obstacle 
we may use a bumper with micro-switches connected 
to a digital input card. Similarly, to control the speed 
of a robot we may use a digital to analog converter 
and DC motors. Armed with the REQ relation, the IN 
relation, and the OUT relation we can derive the SOFT 
relation. The question is, how shall we do this and how 
shall we structure the description of the SOFT relation 
in a language such as RSML~ e ? 

As mentioned above, the system requirements 
should always be expressed in terms of the physical 
process. These requirements will most likely change 
over the lifetime of the controller (or family of simi- 
lar controllers). The sensors and actuators are likely to 
change independently of the requirements as the con- 
troller is reused in different members of a family or 
new hardware becomes available; thus, all three rela- 
tions, REQ, IN, and OUT, are likely to change over 
time. If either one of the REQ, IN, or OUT rela- 
tions change, the SOFT relation must be modified. 
To provide a smooth transition from system require- 
ments (REQ) to software specification (SOFT) and to 
isolate the impact of requirements, sensor, and actu- 
ator changes to a minimum, the structure of the soft- 
ware specification SOFT should be based heavily on 
the structure of the REQ relation [18, 23], 

We achieve this by splitting the SOFT relation into 
three pieces, IN -1 , OUT -1 , and SOFT hj.jq (Figure 2). 
IN -1 takes the measured input and reconstructs an es- 
timate of the physical quantities in MON. The OUT -1 
relation maps the internal representation of the con- 
trolled variables to the output needed for the actuators 
to manipulate the actual controlled variables. Given 
the IN -1 and OUT -1 relations, the SOFTa^q rela- 
tion will now be essentially isomorphic to the system 
requirements (the REQ relation) and. thus, be robust if 
it is reused on a new platform (manifested as changes 
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Figure 2. The SOFT relation can be split 
into three composed relations. 


in the IN and OUT relations). Such changes would 
only effect the IN -1 and OUT -1 portions of the soft- 
ware specification. Tims, the str ucturing approach out- 
lined in this section will makes the SOFT req portion 
of the software specification reusable over members of 
a product family exhibiting the same high-level behav- 
ior. 

4 Mobile Robotics Platforms 

When evaluating our work, we wanted to find a do- 
main were a variety of similar platforms could be con- 
structed on a university budget in a timely and cost 
effective manner. Furthermore, we wanted this do- 
main to be realistic — with the inclusion of noisy sen- 
sors and actuators and the possibility of complex sen- 
sor fusion and error detection. The mobile robotics 
domain seemed ideally suited for these needs. 

The mobile robotics platforms that we are using in 
our research range in size from about the size of the 
Mars Pathfinder to a small lego-bot. The robots have 
a limited speed, and can operate either autonomously 
(via a radio modem or radio Ethernet) or via a tether 
cable going to a personal computer. The robotics plat- 
forms come from various vendors and have a wide va- 
riety of sensors and actuators available. 

The platforms that are discussed in this paper are 
shown in Figure 3 1 . One platform, the Pioneer [1], 
is built and sold by ActivMedia, Inc. The Pioneer in- 
cludes an array of sonar sensors in the front and sides 
that allow it to detect obstacles. To detect collisions, 
the Pioneer monitors its wheels and signals a collision 
when the wheels stall. The Pioneer includes an exten- 
sive control library called Saphira. The Pioneer is con- 
trolled by a radio modem that plugs in to the personal 
computer’s serial port. Saphira manages the commu- 
nication over the radio modem. Saphira is capable of 
implementing complex rule -based control functions; 
however, in our work we are using only the simplest 
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Figure 3. A picture of the robotic plat- 
forms used in this paper 


of Saphira functions that allow us nearly direct access 
to the sensors and actuators. Nevertheless, the level of 
abstraction presented by the Saphira library is signif- 
icantly higher than on the other platform in this case 
study: the lego-bot. 

The lego-bot is a smaller platform built from Lego 
building blocks and small motors and sensors. The 
lego-bot uses a tank-like hack locomotion system and 
has infrared sensors for range detection. The lego-bot 
is controlled via a tether to the robot from the per- 
sonal computer. This tether is connected to a data- 
acquisition card and the software specification for the 
lego-bot behavior must directly manage the low-level 
voltages and signal necessary to control the robot; 
there is very little support for the actuators and sen- 
sors. 

Despite the significant difference between the plat- 
forms, we wanted them to exhibit nearly identical vis- 
ible behaviors; the only difference would be in the 
hardware determined speed of the robot’s movements. 
Therefore, the visible behavior (the REQ relation) for 
each robot is the same. Note that we are not addressing 
non-behavioral requirements such as power consump- 
tion and weai' and tear of hardware components in our 
discussions of reuse. We have focused solely on the 
behavior captured in the requirements. 

5 The REQ relation 

The first step in a requirements modeling project is 
to define the system boundaries and identify the mon- 
itored and controlled variables in the environment. In 
this paper we will not go into the details of how to 


scope the system requirements and identify the mon- 
itored and controlled variables — guidelines to help 
identify monitored and controlled variables have been 
discussed in numerous other places [6, 13, 18], Here it 
suffices to say that the monitored and controlled vari- 
ables exist in the physical system and act as the in- 
terface between die proposed controller (software and 
hardware) and the system to be controlled. 

For the mobile robots, the goal was to construct a 
simple reactive control behavior tiiat would cause the 
robot to explore its environment. To accomplish this 
objective, the robot must be able to perform several 
tasks: 

• If the robot detects an obstacle, it shall attempt to 
avoid it. 

• If the robot collides widi an obstacle, it shall at- 
tempt to recover from die collision and continue 
exploration. 

• In die absence of a collision or obstacle, the robot 
shall proceed to move forward at full speed. 

In this case study, we wanted all robots of the prod- 
uct family to exhibit the same exploratory behavior. To 
capture diis behavior we must discover monitored and 
controlled variables in the environment diat will allow 
us to build the formal model, hi addition, while eval- 
uating candidates for monitored and controlled vari- 
ables we must keep in mind that the REQ model shall 
apply to all members of the product family. 

We identified a robot’s speed and heading as con- 
trolled variables. Speed ranges from 0 to 100 and can 
be mapped into a speed for each family member using 
the maximum speed of the particular robot. Heading 
ranges from -180 to 180 and indicates the number of 
degrees that the robot may have to turn to avoid an ob- 
stacle. 

We identified CollisionDetected, Range, and Ob- 
stacleOrientation as monitored variables. The Colli- 
sionDetected variable is simply a Boolean value which 
is true when there is a collision and false otherwise. 
The Range variable is the distance from the robot to 
the nearest obstacle and the ObstacleOrientation de- 
notes whether the obstacle is straight ahead, or on the 
right or left of the robot. These variables clearly reside 
in the system domain and are sufficient to model the 
desired behavior. If the monitored and controlled vari- 
ables are chosen appropriately, the specification of the 
REQ relation will be focused on the issues which are 
central to the requirements on the system. 

Since our work is based around a modeling lan- 
guage called RSML -6 (Requirements State Machine 
Language without events), a state-based language suit- 
able for modeling of reactive control systems, we pro- 


vide a short introduction to the notation before we con- 
tinue with a discussion of the REQ relation for the mo- 
bile robots. 

5.1 Introduction to RSML -6 

RSML -6 is based on the language Requirements 
State Machine Language (RSML) developed by the 
Irvine Safety Research group under the leadership of 
Nancy Leveson [17], RSML -6 is a refinement of 
RSML and is based on hierarchical finite state ma- 
chines and dataflow languages. Visually, it is some- 
what similar to David Harel’s Statecharts [10, 8, 9], 
For example, RSML -6 supports parallelism, hierar- 
chies, and guarded transitions. The main differences 
between RSML -6 and RSML are the addition in 
RSML -6 of rigorous specifications of the interfaces 
between the environment and the control software, 
and file removal of internal broadcast events. The re- 
moval of events was prompted by Nancy Leveson’s 
experiences with RSML and a new language called 
SpecTRM-RL that she has evolved from RSML. These 
experiences have been chronicled in [16], 

An RSML -6 specification consists of a collection 
of state variables, HO variables, interfaces, functions, 
macros, and constants, which will be briefly discussed 
below. 

In RSML -6 , the state of the model is the values 
of a set of state variables, similar to mode classes in 
SCR [12]. These state variables can be organized in 
parallel or hierarchically to describe the current state 
of tlie system. Parallel state variables are used to rep- 
resent the inherently parallel or concurrent concepts in 
the system being modeled. Hierarchical relationships 
allow child state variables to present an elaboration of 
a particular parent state value. Hierarchical state vari- 
ables allow a specification designer to work at multiple 
levels of abstraction, and make models simpler to un- 
derstand. 

Lor example, consider the behavioral requirements 
for our mobile robots outlined in the introduction to 
tins section. The state variable hierarchy used to model 
the requirements on tins system can be represented as 
in Ligure 4. Tins representation includes both parallel 
and hierarchical relationships of state variables: Fail- 
ure and Normal are two parallel state variables and 
Robot .Recover Action is a child of Normal. 

Next state functions in RSML -6 determine the 
value of state variables. These functions can be orga- 
nized as transitions or conditional assignments. Con- 
ditional assignments describe under winch conditions 
a state variable assumes each of its possible values. 
Transitions describe the condition under which a state 
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Figure 4. The REQ relation state hierarchy 


variable is to change value. A transition consists 
of a source value, a destination value, and a guard- 
ing condition. The two state function types are log- 
ically equivalent; mechanized procedures exist to en- 
sure that both types of functions are complete and con- 
sistent [11]. 

The next state functions are placed into a partial 
order based on data dependencies and the hierarchi- 
cal structure of the state machine. State variables are 
data-dependent on any other state variables, macros, 
or I/O variables that are named in their transitions or 
condition tables. If a variable is a child variable of 
another state variable, then it is also dependent on its 
parent variable. The value of the state variable can be 
computed after the items on which it is data-dependent 
have been computed. For example, the value of the 
Robot Avoid Action state variable would be computed 
after the Obstacle -Distance state variable because the 
action to take is dependent upon the range of the ob- 
stacle. 

Conditions are simply predicate logic statement 
over the various states and variables in the specifica- 
tion. The conditions are expressed in disjunctive nor- 
mal form using a notation called AND/OR tables [17] 
The far-left column of the AND/OR table lists the logi- 
cal pln ases. Each of the other columns is a conjunction 
of those phr ases and contains the logical values of the 
expressions. If one of the columns is true, then the ta- 
ble evaluates to true. A column evaluates to true if all 


of its elements match the truth values of the associated 
columns. An asterisk denotes “don’t care.” Examples 
of and/or tables can be found later in this section and 
in the next section. 

HO Variables in the specification allow the analyst 
to record the monitored variables (MON) or values 
reported by various external sensors (INPUT) (in the 
case of input variables) and provide a place to cap- 
ture the controlled variables (CON) or the values of 
the outputs (OUTPUT) of the system prior to sending 
them out in a message (in the case of output variables). 

To further increase the readability of the specifi- 
cation, RSML~ e contains many other syntactic con- 
ventions. For example, RSML~ e allows expressions 
used in the predicates to be defined as functions and 
familial' and frequently used conditions to be defined 
as macros. Finally, RSML -e requires rigorous speci- 
fication of interfaces between the environment and the 
model. 

5.2 REQ Relation Overview 

Due to space constraints, the entire model of the 
REQ relation cannot be given in this paper and we will 
focus on an illustrative subset. Figure 4 shows that the 
REQ relation definition at the top level is split between 
two state variables: Failure and Normal. The Failure 
state variable encapsulates the failure conditions of the 
REQ relation, whereas the Normal state variable de- 




scribes the how the robot transitions between the vari- 
ous high-level behaviors discussed at the introduction 
to this section (obstacle avoidance, collision recovery, 
etc.). For the reminder of our discussion of REQ, we 
will focus on the Normal state variable where this as- 
pect of the requirements is captured (Figure 5). 

The Normal variable defaults to the startup value. 
This allows the specification to perform various ini- 
tialization tasks and checks before the main behav- 
ior takes over. The first transition in Figure 5 states 
that after two seconds, the specification will enter die 
Cruise -Forward, state. 

The next two transitions govern die way that 
the Normal state variable can change from the 
Cruise-Forward value. If a collision is detected, then 
the state variable changes to the Collision .Recover 
state. If an obstacle is detected, dien the specifica- 
tion will enter die Avoid .Ob stacle state. Odierwise, 
the value of the Normal state variable will remain un- 
changed. 

If a collision or obstacle is detected, die machine 
needs to begin the Cruise .Forward behavior when die 
avoidance/recovery action has been completed. We ac- 
complished this in die mobile robotics specification by 
providing a “done” state in each of the sub-behaviors. 
This is illustrated by the fifth and sixdi transitions in 
Figure 5. 

Finally, it is also possible to transition from 
Avoid. Obstacle directly to Collision Recover if, for 
example, the robot hits an undetected obstacle; this 
case is covered by the final transition in Figure 5. 

Given this definition of the REQ relation high- 
level behaviors, the definitions of the sub-behaviors 
can be constructed in a similar and straightforward 
manner. For example, if the robot hits an obsta- 
cle, it will adempt to back up, turn, and then pro- 
ceed forward again. This behavior is specified in 
the Robot Recover Action state variable by having the 
variable cycle though the values Backward, Turn, and 
finally Done. 

6 The SOFT relation 


|State Variable! 

Normal 

Location: Reactive_Control 


Transition: Startup — ► Craise_Forward 


Condition: 



TIME > 2 s 

T 


..Failure IN_STATE Ok 

T 

Transition: Cmise_Forward— ►Collision_Recover 


Condition: 



CollisionDetectedMacro() = TRUE 

T 


..Failure IN_STATE Ok 

T 

Transition: Cruise_Forward — ►Avoid_Obstacle 


Condition: 



ObstacleDetectedMacro() = TRUE 

T 


CollisionDetectedMacroO = FALSE 

T 


..Failure IN_STATE Ok 

T 

Transition: Collision_Recover — ►Cruise_Forward 


Condition: 



Prev_Step(..Robot_Recover_Action IN_STATE Done) 

T 


..Failure IN_STATE Ok 

T 

Transition: Avoid_Obstacle — ► Cruise_Forward 


Condition: 



Prev_Step(..Robot_Avoid_Acrion IN_STATE Done) 

T 


..Failure IN_STATE Ok 

T 


Transition: Avoid_Obstacle — ► Collision_Recover 

Condition: 


CollisionDetectedMacroO = TRUE 

T 

..Failure IN_STATE Ok 

T 


When refining the specification from REQ to Figure 5. The definition of the Normal 

SOFT, we select the sensors and actuators that will state variable 

supply the software witii information about the envi- 
ronment, that is, we must select the hardware and de- 
fine the IN and OUT relations for each platform. Con- 
sequently, we will also need to define the IN -1 and 
OUT -1 for each platform. We do not have the space 
to discuss the IN, OUT, IN -1 , and OUT -1 for every 
monitored and controlled variable. Instead, we will 
focus our discussion on two areas where the Pioneer 









and the lego-bot presented illustrative and challenging 
differences. 

6.1 Obstacle Detection — 

Sonar versus Infrared 

As members of the mobile robot product family that 
we specified in Section 5. both the Pioneer and the 
lego-bot have the ability to sense the distance to ob- 
jects in their surroundings. Distance sensors typically 
function by emitting some sort of signal (for example, 
a sound in the case of sonar) and then measuring the 
amount of time between the emission of the signal and 
its being received back at the sensor. Given how fast 
the signal can travel, the distance to the closest object 
can be determined. Although the distance sensors may 
be somewhat similar in their operation, different sen- 
sors provide very different accuracies and ranges. For 
example, a laser range finder is far more accurate and 
has much less noise than the sonar sensors. 

The Pioneer uses sonar sensors and the Saphira 
software package to accomplish obstacle detection 
whereas the lego-bot uses a set of simple infrared 
range finders. This significant difference in the type 
of sensors as well as differences in the number and 
placement of the sensors leads to two quite different IN 
relations. The differences of the IN relations necessi- 
tate different IN -1 in the computation of the estimated 
value of the Range monitored quantity. 


|Function| 

PT ransformRange 


Type: INTEGER 
Parameters: 

ilnRange IS INTEGER 


:= OIF 


ilnRange <= 0 

F 

T 

ilnRange > 700 

T 

F 


:= iInRange/7 IF 


ilnRange > 0 

T 

ilnRange <= 700 

T 


Figure 7. IN 1 Range for the Pioneer 

The difference between the SOFT relations for the 
two platforms (with respect to the range to obstacles) 
can be encapsulated in a function which transforms the 
input variables from the range sensors to estimates of 
the monitored quantity Range. The computation of 


[Function! 

LT ransformRange 


Type: INTEGER 
Parameters: 

ilnRange IS INTEGER 


:= OIF 



Figure 8. IN -1 Range for the lego-bot 


IN -1 for the Pioneer is pictured in Figure 7 and for 
the lego-bot is in Figure 8. For the Pioneer, the sonar 
inputs range from 0 to 700 and must be scaled appro- 
priately to a number between zero and 100. 

For the lego-bot, the transformation is more com- 
plex. Both the sonar and the infrared distance sensors 
have a certain range close to the sensor where the sig- 
nals cannot be used for range detection (in the case of 
the sonars, the signals that are emitted bounce back to 
the sensor too fast for the sensor to detect). Titus, the 
sensor will report that no obstacle is present when, in 
fact, an obstacle is very close. In the case of the Pi- 
oneer, this problem is handled by the Saphira library. 
For the lego-bot, however, the RSML~ e specification 
must include a minimum tlueshold as well as a scaling 
factor for the maximum values. In our case, readings 
below 200 from the infrared sensor cannot be trusted 
and we simply treat any reading below 200 as if the 
distance is 0, indicating that no obstacle has been (or 
can be) detected (Figure 8). 

Titus, we have shown that even though the sensors 
and the way in which we have access to the sensors 
differs widely between the Pioneer and the lego-bot, 
we can still use the same SOFTr^q model for both 
robot platforms, hi this way, we make the high-level 
behavior robust and reusable in the face of changes in 
the range finder. 

6.2 Speed — 

Saphira versus Pulse Modulation 

The previous section focused on platform depen- 
dent variabilities in the IN and IN -1 relations. The 
Pioneer and the lego-bot have more significant differ- 








Figure 6. The state machine tor the lego-bot 


ences in the way that they control their propulsion and 
in their steering systems (the OUT and OUT -1 rela- 
tions). 

The Pioneer’s Saphira library provides a high-level 
control of the Pioneer’s motors so that the specifica- 
tion for SOFT on the Pioneer platform is very simi- 
lar to REQ. The transformation of the desired speed 
performed in OUT -1 for the Pioneer (Figure 9) only 
requires some minor scaling with respect to the Pio- 
neer’s maximum speed. The result of this transforma- 
tion can then be directly sent to the Pioneer platfonn 
and Saphira will control the hardware to achieve the 
desired speed. 


|Function| 

PT ransformConSpeed 


Type: INTEGER 
Parameters: 

iConSpeed IS INTEGER 


:= OIF 



iConSpeed = 0 

□ 

:= (PMaxSpeed * iConSpeed)/100 IF 


iConSpeed = 0 

□ 


Figure 9. OUT -1 Speed for the Pioneer 


|State Variable^ 

MotorPulseSlatus 

Location: ..MotorOn 

Transition: Off® On 
Condition: 


TIME >= PREV STEP (..MotorPulseStatus TIME_ENTERED Off) + 
LMotorPWMTimeOut(Heading, ConSpeed) 

T 

PREV_STEP(.. MotorPulseStatus IN_STATE Off) 

T 


Transition: On ® Off 
Condition: 


TIME >= PREV_STEP(.. MotorPulseStatus TTME_ENTERED On) + LPWMOnTimeOut 

T 

PREV_STEP(.. MotorPulseStatus IN_STATE On) 

T 

ConSpeed =100 

F 


:= On 

Condition: 

I ConSpeed = 100 Tr 


Figure 10. The part of OUT -1 for the 
Lego-bot that performs the pulsing on 
the motors 


On the other hand, the OUT 1 specification for the 
speed of the lego-bot is significantly more complex. 






This is because the SOFT relation for the lego-bot 
must control the motors directly with low-level hard- 
ware signals. The speed of the lego-bot is controlled 
by a technique called pulse-width modulation of the 
DC motors: the speed of the motors is determined by 
the length of tune which passes between pulses of cur- 
rent applied to the motor. Therefore, the SOFT specifi- 
cation cannot simply output the speed value with some 
transformation applied; instead, we must use die com- 
puted value for the controlled variable Speed to deter- 
mine the pulse width for the motors and then output 
the pulses accordingly; die motors will then provide 
enough propulsion to move the lego-bot at die desired 
speed. 

This control strategy necessitates a more complex 
OUT -1 relation for the desired speed; the OUT -1 re- 
lation can no longer be a simple function — in diis case 
we need to add an additional state machine. To model 
the pulse modulation we add a state variables to the 
SOFT specification so that die machine can output the 
required pulses. These additions are shown in Fig- 
ure 6. The MotorPulseStatus state variable is the part 
of the OUT -1 specification diat determines the pulse 
width. Figure 10 shows die definition of this state vari- 
able. 

A key component of the pulse-width modulation is 
the LMotorPWMTimeOut function which determines 
the length of time to pulse the motors (Figure 11). No- 
tice that because of the lego-bot ’s tank- track propul- 
sion system, the motors must be pulsed both in the case 
of a turn and in the case that the robot is moving for- 
ward. Thus, the LMotorPWMTimeOut function takes 
as parameters the controlled variables for speed and 
heading and produces the correct timeout values. 

The values for the pulse intervals were were cho- 
sen by running experiments to determine which pulse 
interval would achieve which speed. We have, there- 
fore, encapsulated these constants so that if we were to 
change motors on the lego-bot in the future we could 
simply change the constants rather than having to re- 
visit the pulse- width modulation process. 

Tlius, despite the fact that the Pioneer and the lego- 
bot differ significantly in the way that the motors are 
controlled, the SOFT req relation can again be reused 
across the platforms. Furthermore, changes in the 
REQ relation (and analogous changes to SOFT req) 
will be independent of changes in the OUT and 
OUT -1 relations. 

7 Conclusions 

This paper describes how structuring the require- 
ments based on the relationship between the system 


|FunctioH 


LMotorPWMTimeOut 


Type: TIME 
Parameters: 

• iHeading IS INTEGER 
iConSpeed IS INTEGER 


:= LSlowPWMOffTimeOut IF 


iHeading = 90 

T 

F 

F 

iHeading = -90 

F 

T 

F 

iConSpeed = 25 

F 

F 

T 


:= LMidPWMOffTimeOut IF 


iHeading = 45 

T 

F 

F 

F 

iHeading = -45 

F 

T 

F 

F 

iConSpeed = 50 

F 

F 

T 

F 

iConSpeed = -50 

F 

F 

F 

T 


:= LFastPWMOffTimeOut IF 


iHeading = 20 

T 

F 

F 

iHeading = -20 

F 

T 

F 

iConSpeed = 75 

F 

F 

T 


:=0 s IF 


iConSpeed = 100 I T 


Figure 11. The timeout function for 
pulse-width modulation on the Lego-bot. 






requirements and the software specification can lead 
to benefits in terms of maintainability and reusability. 
Specifically, we describe a technique for structuring 
high-level requirements for reuse in the face of hard- 
ware changes. 

From file four variable model for process control 
systems, we have described how the REQ relation can 
be refined to file SOFT relation while maintaining a 
separation between the part of SOFT which is related 
to REQ ( SOFT rjcq ) and file parts of SOFT which han- 
dle file particular sensors and actuators in the system 
design (IN -1 and OUT -1 ). This allows us to sepa- 
rate changes in the requirements from sensor and ac- 
tuator changes and achieve better maintainability and 
reusability. 

This teclmiques was demonstrated on a case study 
in file mobile robotics domain using two quite differ- 
ent robots. One robot is commercially produced and 
is equipped with a rich control library that provides 
many complex control functions, for example, travel- 
ing at a requested speed. The other robot was build in- 
house from Lego building blocks and off-the-shelf mo- 
tors and sensors. This robot is controlled completely 
by file software specification in RSML -e through our 
Nimbus toolset. 

We demonstrated the usefuhiess of the structur- 
ing approach by reusing the high-level requirements 
(REQ) across a (currently quite small) family of mo- 
bile robots. Nevertheless, there are numerous issues 
left to address. In the future, we plan to define more 
complex control behaviors and investigate how indi- 
vidual behaviors (or operational modes) can be suc- 
cessfully reused. 
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Abstract 

This paper describes the intermediate results of a 
project to develop automated, high integrity, software 
verification and validation techniques for aerospace ap- 
plications. Automated specification validation and test 
case generation are made possible by the targeted use 
of formal methods. Specifically, the restricted domain of 
use is exploited to reduce the set of mathematical prob- 
lems to those that can be solved using constraint solvers, 
model checkers and automated proof tactics. The prac- 
ticality of the techniques is enhanced by the tight inte- 
gration of the formal methods to intuitive specification 
notations, existing specification modelling tools and a 
traditional software development process. 

This paper presents evidence to support an emerging 
appreciation amongst the software engineering commu- 
nity that, for the benefits of formal methods to be widely 
exploited in industry, an approach must be taken that in- 
tegrates formal analysis with intuitive engineering nota- 
tions, traditional engineering approaches and powerful 
tool support. 

1. Introduction 

It is widely accepted that verification and validation 
(V&V) activities for high integrity systems are expen- 
sive (typically over 50% of total software development 
costs [2]). The requirements for such systems are of- 
ten subject to change throughout the project so the high 
V&V costs are normally incurred not only once, but 
many tunes. Also, the cost of fixing errors later in the 
development life-cycle can be many tunes more than 
if they were identified during the phase in which they 
were introduced. Additionally, commercial pressures to 


reduce time to market, technological conservatism and 
the need to meet standard test metrics make the software 
V&V process a highly fragile and risky component of 
system development. 

The use of formal methods has long been advo- 
cated as a means of improving the development of high 
integrity systems. Despite evidence to support this 
claim, e.g. [14, 17], formal methods have still to gain 
widespread use in the software industry. Industrial ac- 
ceptance of formal methods requires the development of 
powerful tools to support formal analysis, pragmatic ap- 
proaches to using these tools within a software process 
and more industrially applicable examples of the suc- 
cessful use of formal methods [6, 15]. Also, for the en- 
gineers with the system domain knowledge to be able 
to perform V & V there is a need, as Ould [22] put it, to 
“disguise” the formality so that an impractical amount 
of formal methods skill is not a pre-requisite to effective 
V&V. 

This paper describes the results of a project that 
has achieved practical integration of automated formal 
methods for V&V into an industrially applicable soft- 
ware development process. The paper is structured as 
follows: Section 2 introduces the background and ob- 
jectives of the work reported here. Section 3 describes 
the translation of domain specific, intuitive engineer- 
ing notations into formal specifications. Section 4 de- 
scribes how these intermediate formal specifications can 
be used to automatically analyse certain properties of 
the requirements specification. Section 5 describes a 
method of automated test case design and test data gen- 
eration. based again on the intermediate formal spec- 
ification. Section 6 presents some results of applying 
the techniques in practice and gives an evaluation of the 
work so far. Section 7 presents some conclusions and 
suggests directions for future work. 



2. Background and objectives 

The work reported here is being undertaken as part 
of a process improvement programme to demonstrate a 
“better, faster, cheaper” software process for develop- 
ing Electronic Engine Controllers (EECs) for aircraft en- 
gines. These are real-time, safety critical, fault-tolerant 
computer systems embedded in complex engineering 
products. The contribution of the V&V strand of the 
process improvement work (the subject of this paper) is 
to develop efficient and effective V&V techniques that 
can be smoothly integrated into a practical engineering 
process. 

The use of formal methods is intended to increase 
the integrity of engineering activities already performed 
such as specification and testing. These improvements 
must be implemented within a process that engineers 
can use with the minimum amount of re-training. There- 
fore intuitive engineering notations have been retained 
as a means of software specification and techniques have 
been developed to increase the integrity of these specifi- 
cations through the use of automated formal analysis. 

Although this research is targeted towards specifica- 
tion validation and software testing, it is acknowledged 
that significant benefits in these areas can not be at- 
tained without improving the rigour and consistency of 
the requirements specifications. Specification notations 
are therefore used that are both “engineer friendly” and 
amenable to formal analysis. The savings demonstrated 
in the validation and testing phases serve as drivers to 
encourage investment in these improved specification 
activities. It is expected that the most significant cost- 
benefits can be achieved by capturing more requirements 
and software specification errors at the specification val- 
idation phase (therefore reducing the number of itera- 
tions of file software design, coding and testing phases) 
and by automating test case generation (one of the most 
time consuming parts of the present process). 

3. Translating engineering notations into 
formal specifications 

Domain specific graphical engineering notations are 
popular with engineers, but their semantics are often un- 
clear from inspection of the diagrams alone. In reality, 
it is also unlikely that only one notation will be used to 
specify a system, or indeed that notations will be used 
consistently between projects. The resulting loose spec- 
ification and inconsistency complicates the task of au- 
tomating specification validation and test case genera- 
tion based on these notations. Indeed as the notations 
change so frequently (as a result of commercial trends, 
new or outdated tool-support etc.) it may not even be 


cost effective to invest in automated V&V tool support 
which may in practice only have a limited life-span and 
audience. 

Translation of the graphical requirements into a core 
formal notation removes the vagueness of the original 
notations and makes the behaviour implied by the spec- 
ification explicit for the purposes of V&V. Validation 
may thus be supported by rigorous (or formal) reason- 
ing using the formal representation. Also, by explicitly 
rendering all specified behaviour, the intermediate repre- 
sentation is a strong basis for automated test case design. 
The use of a common formal notation to model several 
engineering notations facilitates re-use of the analysis 
and test techniques. The introduction of a new notation 
requires only a translation to the formal notation, after 
which the previously developed tools and heuristics can 
be re-used. A strict translation process allows a fixed 
structure to be enforced on the resulting formal specifi- 
cation that can be exploited in the development of au- 
tomated heuristics, e.g. test data generation procedures 
and proof tactics. 

The work reported here focuses on the specification, 
validation and verification of the discrete aspects of en- 
gine controllers (well-established mathematically based 
processes were already in place for modelling and vali- 
dating the continuous aspects of the control software - 
e.g. the control laws). The Practical Formal Specifica- 
tion (PFS) notation [7, 19] is used to specify the func- 
tional software requirements. The PFS notation consists 
of hierarchical state machines (in particular, a dialect of 
statecharts 1 [9]) and tabular forms, such as those em- 
ployed in SCR (Software Cost Reduction) e.g. [12]. The 
notation has so far proven popular with the engineers 
introduced to PFS 2 . PFS also provides a theory for com- 
bining components specified in the notation - based on 
weakest precondition reasoning - and a set of suggested 
“healthiness properties” that specifications should dis- 
play to be considered valid. 

One of the cornerstones of the PFS approach is that 
engineers are not only required to specify the intended 
behaviour of components of the system, they are also 
obliged to state explicitly the assumptions on which 
each component relies, i.e. its domain of applicability. 
Healthiness conditions can then be stated and discharged 
to demonstrate that, for instance, within the assumptions 
of each component the behaviour is completely and un- 
ambiguously defined. Additionally, healthiness condi- 
tions are stated to demonstrate that where behaviour is 
scoped by assumptions, it is only ever used when the 
required assumptions hold. 

'The state -based notation employed in this paper, a subset of Stat- 
echarts, differs slightly from that usually employed in PFS. 

2 Who have stated that they find the notation valuable even without 
the added rigour provided by a formal underpinning. 




Figure 1. Thrust Reverser System (De- 
ployed) 


Due to the restricted domain, the specifications 
shared some common attributes which reduced the set of 
(mathematical) problems that needed to be solved when 
applying the formal analysis: 

• The software requirements did not involve the stor- 
age and maintenance of complex information struc- 
tures, typically only fixed-point numbers, condi- 
tions and enumerated types were used. 

• In the control software domain, non-determinism 
(looseness) as a means of abstraction is difficult to 
apply 3 . In the example given here, the requirements 
were tightly specified, only one outcome was to be 
specified for each situation 4 . 

PFS components are either reactive (the outputs de- 
pend only on the current set of inputs) and specified us- 
ing tables, or else state-based (the outputs depend on 
both the current inputs and the current state of the sys- 
tem) and specified using annotated state-machines. 

The example used to illustrate the techniques re- 
ported in this paper is the specification of a thrust re- 
verser deployment mechanism. The thrust reverser pro- 
vides part of the retarding force for an aircraft on land- 
ing (see figure 1). It slows the aircraft by using pivot- 
ing doors to redirect the engine thrust. For the puipose 
of clarity and brevity, we will present a much simpli- 
fied version of the specifications, although then essence 
is retained. A real thrust reverser system was used as 

3 The controlled environment is understood in terms of the great 
many relationships between physical quantities, as a result the expres- 
sion of requirements ate highly explicit and deterministic. 

4 Although PFS notation does allow some non-deterministic ab- 
stractions to be used in certain situations [7], 


the primary case study for evaluating the techniques de- 
scribed here. The software specification used for the 
case study consisted of 70 pages of PFS tables and stat- 
echarts, component combination diagrams and support- 
ing text. 

Examples of software requirements written in PFS 
are given in figures 2 and 3. Figure 2 describes a func- 
tion that returns a boolean value ( DoorDeployed) corre- 
sponding to whether a door is locked into its deployed 
position or not. The assumption defines the context 
in which the component may be safely used (in this 
case, the conditions under which sensor values may be 
deemed to be valid). The guard/definition pairings de- 
fine file conditions (guards) under which the function 
returns particular values (definitions). A state-machine 
that specifies which commands should be sent to the 
door actuators based on the pilot actions and current 
door position is given in figure 3. The part of the tran- 
sition labels before the 7’ defines the condition under 
which the transition is taken. The rest of the label de- 
fines the action to be performed on taking the transition. 
The values for DoorDeployed, DoorStowed and Pilot- 
Command are calculated based on functions defined in 
the reactive notation. Likewise the Door Actuators com- 
mand would be transformed into actuator signals based 
on file command and a number of environmental and po- 
sitional inputs. This function would also be specified in 
the reactive notation. 

Both the reactive and state-based components are 
translated into formal specifications (we use the model- 
based notation Z [24] due to the large amount of local 
experience and existing in-house tool support). The se- 
mantics of PFS notations has been formally specified 
also using Z and this is used to define the translation 
from the reactive components into Z. The state-based 
components are modelled using Statemate [10] (a com- 
mercially available tool that allows Statecharts to be en- 
tered and animated via a mouse-driven interface). The 
semantics used by the tool are well-documented [11] and 
have also been formally specified [20, 29], These se- 
mantics are used to define the translation from the State- 
charts into Z. The formal specifications for both notation 
types are structured as follows: 

• Auxiliary definitions: These may include defini- 
tions of types, constants and relations used to con- 
strain file system according to the static semantics 
of file engineering notation. 

• Global State ( for Statecharts only): Contains all in- 
formation relating to the persistent state of the sys- 
tem. This may include a set of currently active be- 
havioural states, active events and the values of all 
data variables local to the statechart. The global 
state is constrained by semantic relations specified 



Function: 

DoorDeployed 

Assumption: 

FullyRetracted < RamPosition < 
FullyExtended AND 0 < Hinge < 90 

Guard 1: 

RamPosition > DeployedPosition AND Hinge > 
80 AND DeployLock = Activated 

Definition 1: 

True 

Guard 2: 

RamPosition < DeployedPosition OR Hinge < 
80 OR DeployLock = Deactivated 

Definition 2: 

False 


Figure 2. Reactive component tor sensing thrust reverser door deployment 



not (PilotCoinmand=Stow) and not (PilotCoimnand=Deploy) and 

DoorDeployed=False/ DoorStowed=False/ 

DoorActuators= Deploy DoorActuators=Stow 


Figure 3. State-based component for controlling door deployment 


in the auxiliary definitions (defined in terms of a 
state invariant). 

• Operations: The dynamic behaviour of the system 
is specified as a set of operations. Each operation 
defines a transformation of the global state (for stat- 
echart operations only) and inputs to the compo- 
nent in terms of a pre-condition. A post-condition 
constrains the next value of the global state (for 
Statecharts operations only) and a definition of the 
outputs of the component. One operation is speci- 
fied for each reactive definition and for each state - 
chart transition. These operations form the basis of 
the specification validation and test case generation 
activities described in the following sections. 

The Statemate [10] tool provides an “Application 
Programming Interface” (API), that allows direct access 
to the internal form of the specification. An interfacing 
tool, called StateZ, was written by the authors, that takes 
tins internal form and, based on an understanding of the 
formal semantics of the Statecharts, directly generates 
a formal specification of the statechart in Z. Included 
in this specification are the accompanying proof conjec- 


tures required to discharge particular healthiness checks 
of the specifications (see section 4) and automatically 
generated English language annotations. Tins informal 
text provides the traceability between the formal opera- 
tions and their corresponding part in the original require- 
ments or a description of the property which the conjec- 
tures are used to prove. These annotations not only allow 
the generated Z document to be reviewed for correctness 
with respect to the original requirements (verifying the 
automated translation) but also form the basis of the test 
descriptions which are used to associate each test with 
the property in the requirements being checked. The ad- 
dition of the informal text generation to the translation 
tool was found to greatly increase the readability and us- 
ability of the formal specification and associated tests. 

The Statemate and StateZ tools can be run in parallel, 
allowing the Z to be re-generated whenever a change is 
made to the Statecharts. Coupled with the automated 
theorem proving described below, this allows the formal 
analysis to be used as a development aid rather than a 
separate post development activity. 

At present, no tool support exists for translating the 
PFS reactive notation into Z (tins step is done by hand) 






and therefore the checking of the reactive components 
was not as tightly integrated into the specification pro- 
cess as for the Statecharts, however we predict that this 
should not present any technical difficulties, given a suit- 
able method of electronically recording and managing 
the reactive tables. 

4. Specification validation 

In current industrial practice, many requirements er- 
rors are only found once the system has been imple- 
mented. Detecting them at an earlier stage in the de- 
velopment would greatly reduce the cost of (both imple- 
mentation and V&V) re-work. This can best be achieved 
by applying a variety of diverse methods to validate the 
requirements specifications. These can include peer re- 
view, model animation (as supported by tools such as 
Statemate) and automated formal analysis. The use of 
intuitive engineering notations would normally exclude 
the possibility of applying formal analysis. However, 
based on the same mapping used to generate the formal 
specification, specification healthiness conditions can be 
couched as formal constraints. Formal analysis can then 
be used to show the truth (or otherwise) of these con- 
straints. 

Completeness 5 and determinism 6 are two of the 
healthiness conditions suggested by the PFS approach. 
If the behaviour of a component is defined as a set of 
operations {Opi, Op 2 , ■■■Op„} over the inputs and state, 
then a conjecture on the completeness of the specifica- 
tion of that component can be formulated as follows: 

F V GlobalState, Inputs • Assumptions =>• 
pie Op i V pie Op 2 V . . . pre Op„ 

Informally, for each possible value of the global state 
(if there is one) and each combination of inputs that sat- 
isfy file validity assumptions of the component, the pre- 
condition of at least one operation is satisfied. 

A similar conjecture can be defined to show the de- 
terminism of the operations. Each combination of global 
state and inputs that satisfies the component validity as- 
sumption must satisfy at most one operation. 

F V GlobalState, Inputs • Assumptions =>• 

Vi : \..n — 1 • Vy : i -F l..n • 

-■(pre Opi A pre Opj) 

5 The behaviour of a system is defined for each combination of in- 
puts and current state. 

6 The behaviour of a system is unambiguously defined for each 
combination of inputs and current state. 


Completeness and determinism conjectures for the 
example reactive definition and state-based component 
are shown in figures 4 and 5 respectively. 

F V RamPosition : N; Hinge : N; 

DeployLock : Activated \ Deactivated • 

{FullyRetracted < RamPosition < FullyExtended 
A 0 < Hinge < 90) 

{RamPosition > DeployedPosition A 
Hinge > 80 A DeployLock = Activated ) V 
{RamPosition < DeployedPosition V 
Hinge < 80 V DeployLock = Deactivated) 

Figure 4. Completeness conjecture for Do- 
orDeployed 


F V State : Idle \ Deploying \ Stowing ; 

PilotCommand : Off \ Deploy | Stow, 

DoorDeployed : Boolean ; 

DoorStowed : Boolean • 

State = Stowing =>■ 

->( DoorStowed = True A 
-i . PilotCommand = Deploy A 
DoorStowed = False ) A 
-i ( DoorStowed = True A 
PilotCommand = Deploy ) A 
-i(-i PilotCommand = Deploy A 
DoorStowed = False A 
PilotCommand = Deploy ) 

Figure 5. Determinism conjecture for Stow- 
ing 

Closer inspection of these two conjectures show that 
they are invalid. For the reactive component, no out- 
come is specified if the hydraulic ram is exactly at the 
deployed position or the hinge is at exactly 80 degrees. 
For the state-based component, it is not clear to which 
state the machine should move while in the Stowing 
state if the pilot requests deployment at the same mo- 
ment as the doors become stowed. Depending on the 
behaviour specified within the Idle and Deploying states 
(these could be super-states encapsulating more detailed 
behaviour) taking one transition over another may have 
a serious impact on the behaviour of the system. 

The conjectures that arose from the case studies were 
proven using CADiZ [26, 28], CADiZ is a general pur- 
pose Z type checker and theorem prover that allows a 
user to interactively browse, type check and perform 



DoorDeployedOperation 

RarnPositionl : N 
Hinge ? : N 

DeployLock ? : Activated \ Deactivated 
DoorDepIoyedl : Boolean 

(FullyRetr acted < RarnPositionl < FullyExtended A 0 < Hinge ? < 90) => 

(( RarnPositionl > Deploy edPositi on A Hinge ? > 80 A DeployLockl = Activated) A 
DoorDepIoyedl = True) V 

(( RarnPositionl < Deploy edPositi on V Hinge 1 < 80 V DeployLockl = Deactivated) A 
DoorDepIoyedl = False) 


Figure 6. Z operation schema for DoorDeployed 


proofs upon a Z specification. CADiZ allows gen- 
eral purpose proof tactics to be written in a lazy func- 
tional notation [27], these can be invoked from within 
a CADiZ window and applied to any proof obligation 
on the screen. This level of proof tactic re-use is possi- 
ble because of the consistent structure of the complete- 
ness and determinism conjectures. A proof tactic has 
been written to prove the determinism and completeness 
conjectures. The tactic first simplifies the constraint and 
then calls either the SMV [3] model checker (most suit- 
able for predicates involving finite types) or a simulated 
annealing based constraint solver [4] (used for counter- 
example generation for predicates involving mixed nu- 
meric types including integers and reals). If the check 
fails, a counter-example is given. This information has 
been found to be extremely valuable when tracking the 
error in the specification. Conjectures that can not be au- 
tomatically discharged in this way involve a mixture of 
enumerated and infinite numeric types. This combina- 
tion is not currently supported by the constraint solvers. 
Restricting the numeric types to sensible finite ranges 
allows these constraints to be checked automatically. 

The healthiness checks that failed have been found to 
be due to areas of omission or ambiguity in the original 
system requirements that were not detected through re- 
view or animation. Tins illustrates that there is much 
benefit to be obtained by verifying relatively simple 
properties of the specifications and the high level of au- 
tomation ensures that the only additional work required 
is that of locating the errors in the specification based 
on the counter-examples. This work would otherwise be 
done at a later stage with perhaps less illuminating data 
to work from. 

The high level of automation allows the analysis to be 
re-run each tune the specification is changed, further re- 
ducing the cost of rework. Although the interactive ver- 
sion of CADiZ allows the proof effort to be automated 


it still requires some repetitive work from the user to 
load the generated Z file and select each proof obliga- 
tion in turn to apply the proof tactics. Work is under- 
way to encapsulate the functionality of CADiZ within 
an API. This will provide the opportunity to fully in- 
tegrate the formal analysis into specification modelling 
tools. Instant feedback on the properties being analysed 
can then be presented to the user using the same format 
as file original specification. The details of the analysis 
would be recorded (as the intermediate specification and 
proofs in Z) for review by engineers with the relevant 
fonnal methods skills. 

5. Automatic test case generation 

The fonnal specification describes each atomic action 
defined by the requirements specification. These opera- 
tions can be used as basic test specifications. If data can 
be found to satisfy these constraints, the results of apply- 
ing the data to the implementation can be used to gain 
confidence in its correctness with respect to the specifi- 
cation. The success of testing depends on the ability to 
select data that demonstrates the presence of a fault in 
the program. Category -partitioning [21] is a method of 
deriving tests based on a fonnal specification and testing 
heuristics based on common error types. Test data gen- 
erated for the partitioned specification is then assumed 
to have a greater chance of detecting errors in the imple- 
mentation (at least errors of the type used to formulate 
the testing heuristic). This approach was first applied 
to fonnal specifications by Ostrand and Balcer [21] and 
has been developed and applied to the fonnal specifica- 
tion notation Z by Stocks and Carrington [25]. 

The category-partition method is based on the theory 
of equivalence classes [8]. The input domain of the test 
specification is partitioned into sets of data that exhibit 
the same behaviour in the specification. If the equiva- 



DoorDepIoyedOperationPartitionl 

RarnPositionl : N 
Hinge 1 : N 

DeployLock 1 : Activated \ Deactivated 
DoorDeployedl : Boolean 


{Fully Retracted < RarnPositionl < FullyExtended A 0 < Hinge 1 < 90) 

( RamPosition? = Deploy edPosition A 


{RarnPositionl > DeployedPosition A Hinge 1 > 80 A DeployLock 1 = Activated) A 
DoorDeployedl = True) V 

{{RarnPositionl < DeployedPosition V Hinge 1 < 80 V DeployLockl = Deactivated) A 
DoorDeployedl = True) 


Door Deploy edOperation Par ntion‘2 

RarnPositionl : N 


Hinge 1 : N 

DeployLockl : Activated \ Deactivated 
DoorDeployedl : Boolean 


{Fu11yRe.tr acted < RarnPositionl < FullyExtended A 0 < Hinge 1 < 90) 

( RamPosition? = DeployedPosition + 1 A 


{RarnPositionl > DeployedPosition A Hingel > 80 A DeployLockl = Activated) A 
DoorDeployedl = True) V 

{{RarnPositionl < DeployedPosition V Hingel < 80 V DeployLockl = Deactivated) A 
DoorDeployedl = 7h/e) 


Door Deploy edOperation Partition! 

RarnPositionl : N 
Hingel : N 

DeployLockl : Activated \ Deactivated 
DoorDeployedl : Boolean 


{FuIIyRetracted < RarnPositionl < FullyExtended A 0 < Hingel < 90) 

( RamPosition? > DeployedPosition + 1 A 


{RarnPositionl > DeployedPosition A Hingel > 80 A DeployLockl = Activated) A 
DoorDeployedl = True) V 

{{RarnPositionl < DeployedPosition V Hingel < 80 V DeployLockl = Deactivated) A 
DoorDeployedl = True) 


Figure 7. Test partitions tor DoorDeployed 


lence class hypothesis is assumed to hold in the imple- 
mentation, only a selection of data from each equiva- 
lence class is needed to show that the implementation 
satisfies the specification for all data in that class. 

As an example, the operation defining the DoorDe- 


ployed function (from figure 2, but corrected based on 
the completeness analysis described above) will now be 
partitioned to verify that the boundary used to define 
when the hydraulic ram is in the deployed position is 
correctly implemented in the code. The Z specification 


VX, F:N«I>FO 
X = Y V 
X = Y + 1 V 
X > Y + l 

Figure 8. Generic test heuristic tor > 

of the operation is given in figure 6. The ? and ! dec- 
orations are used to distinguish between the input and 
output parameters to the schema. Based on the assump- 
tion that errors often occur on or around boundaries, ap- 
plying a boundary value analysis partitioning strategy 
would result in the partitions shown in figure 7. The ad- 
ditional constraints added by the partitioning are shown 
in bold. These partitions together with those generated 
for the condition where the hydraulic ram is not in the 
deployed position, from the second guard in figure 2, 
fully test the boundary. 

The category-partition method has been automated as 
extensions to the CADiZ theorem prover. Partitioning 
heuristics are specified as lemmas and general-purpose 
proof tactics are used to apply the heuristics via the 
graphical user interface. The predicate to be partitioned 
is highlighted and a proof tactic invoked via a menu 
option which automatically introduces the partitioning 
heuristic into the operation conjecture, instantiates the 
generic heuristic with the operands of the predicate and 
simplifies the whole conjecture to reveal a disjunction 
of partitions. Each partition is then converted into a sep- 
arate schema operation. The lemma used to create the 
partitions shown in figure 7 is given in figure 8. The 
user is also given the opportunity to amend the support- 
ing English language description of the operation being 
partitioned, to include for example the rationale behind 
using the particular partitioning strategy. 

The method of specifying the heuristics as lemmas, 
stored in a separate Z library hie, which are then ‘cut’ 
into the operation has several important advantages. 
Properties of the heuristics themselves can be proven 
(e.g. that the partitions together maintain the state-space 
of the operation). If more heuristics are required (e.g. 
based on common errors specific to the system under de- 
velopment), they can be added without making a change 
to the software itself. The test specifications can be in- 
stantiated with test data via a similar mechanism to the 
test partitioning. The test specification is highlighted 
and an option called from within a CADiZ menu. A 
proof tactic is then automatically applied that simplifies 
the constraint and applies either the SMV model checker 
or simulated annealing constraint solver to generate a set 
of data satisfying the test specification. 

Once the test data has been generated, CADiZ pro- 


duces a corresponding AdaTEST [16] test script. AdaT- 
EST provides a harness for automating the execution, 
checking and documentation of tests for software writ- 
ten in the Ada language. AdaTEST can also record the 
structural code coverage achieved by running the tests. 
Manually producing these test scripts, consumes a large 
proportion of the test engineers time. By automating 
this step, effort that was previously required for test im- 
plementation can now be redirected towards more rigor- 
ous test design. The generated test scripts also include 
the informal text derived from the original requirements 
and annotated with the test rationale during partition- 
ing. This text is automatically included in the AdaTEST 
test results hie and provides the traceability between any 
suspected fault in the program, the requirement under 
test and the heuristic used in designing the test. 

The test specifications for the case study were first 
partitioned to give Modified Condition/Decision Cover- 
age 7 (MC/DC) of each operation. Additional tests were 
then generated based on other heuristics, such as bound- 
ary value analysis. If full MC/DC (as mandated by 
certification standards such as D0-178B [23]) was not 
achieved by running these tests, it was assumed that the 
untested code represented refinements in the design or 
potential errors. Additional manual test effort then con- 
centrated on writing tests for and reviewing these po- 
tentially problematic areas of code. The targeting of 
testing resources in this way was made possible by the 
high amount of automation achieved in generating the 
requirements covering tests. 

6. Results and Evaluation 

A summary of the specification validation and test- 
ing work performed for the tluust reverser case study 
is shown in figure 9. The numbers include only auto- 
matically generated proof obligations and tests and the 
requirements errors found by discharging the proofs. An 
activity is said to be automated if it requires at most 
a single interaction from the user to perform (e.g. a 
proof is discharged by selecting a completeness conjec- 
ture and choosing “Completeness Check” from the on- 
screen menu). Consequently these activities take very 
little time to perform. Many of the proof obligations 
stretched over 4 pages of formal text. Each of these 
would have taken an engineer a significant amount of 
time to prove or disprove. On a Pentium II 400 MHz 
computer running the linux operating system, the largest 
of these proofs took no more than a second to discharge. 

The activities in the process described in this paper 
that have so far' been automated are: automatic genera- 
tion of a formal specification and associated healthiness 

' MC/DC is achieved by showing that each condition within a de- 
cision can independently affect that decision’s outcome[23]. 



State-based components: 

State -machines 9 

States 48 

Transitions 1 12 

Z operations 112 

Specification validation proofs 74 

Automatically discharged proofs 74 

Requirements errors found 18 

Automatically generated tests 262 

Reactive components: 

Tables 34 

Definition/Guard pairings 84 

Z operations 34 

Specification validation proofs 62 

Automatically discharged proofs 52 

Requirements errors found 18 

Automatically generated tests 237 


Figure 9. Summary of results 

property proof obligations from a Statechart modelled 
using STATEMATE, automatic proof or generation of a 
counter-example for PFS (Statechart and tabular) com- 
pleteness and determinism healthiness properties, auto- 
matic partitioning of formally specified operations (de- 
rived from Statecharts of tabular requirements) into test 
cases based on pre-defined heuristics and the automatic 
generation of test data for the partitions and associated 
AdaTEST test script. Activities that we believe can be 
automated or are already in the process of being auto- 
mated are; automatic generation of a formal specifica- 
tion and associated healthiness proof obligations from 
PFS tabular requirements (given a consistent form of 
recording and managing these requirements), automatic 
identification of the healthiness property proof obliga- 
tions within the Z specification and application of the 
appropriate proof tactics and the automatic selection of 
partitioning strategies to generate test sets to satisfy par- 
ticular structural specification coverage criteria. 

The results show that a significant number of require- 
ments errors were detected for little additional effort. 
All the requirements errors detected using this method 
manifested themselves as either non-determinism or in- 
completeness of the specification (as would be expected 
based on the nature of the checks). On analysis of 
these errors we discovered two distinct causes. The first 
type of error was the result of a mis-interpretation of 
some higher level requirements that resulted in an in- 
correct specification with respect to these requirements. 
These errors accounted for the greater proportion of to- 
tal requirements errors found. The second type of error 
was non-determinism or incompleteness as the result of 
some omission or ambiguity in the higher level require- 


ments. Although these errors were less frequent (poten- 
tially because the analysis was not specifically targeted 
at validating the higher level requirements) they were 
deemed to be very valuable. 

A far greater number of tests were generated than 
would have been written for a specification of this size 
using the traditional process. The number of tests that 
can be written are typically restricted by the time it 
takes to design, implement and evaluate each test, in 
the process described here much of this effort has been 
automated, greatly reducing the amount of effort per 
test case. When the analysis or test revealed an er- 
ror, the time taken to review and rework the error var- 
ied according to the nature of the problem. However, 
the impression amongst those involved was that the 
counter-example information and supporting informal 
text greatly contributed to the process of tracking down 
the errors in the requirements. It was also noted that as 
the case study progressed the number of requirements 
errors being detected decreased significantly. The feed- 
back from the formal analysis was thought to have influ- 
enced the style of requirements specification, i.e. the au- 
thor of the requirements was consciously writing speci- 
fications to meet the healthiness conditions specified by 
the PFS methodology. 8 

In [18], Knight presented the following criteria for 
industrial acceptance of formal methods. Based on the 
evidence from the case study and experience of work- 
ing with our industrial partners we can now assess the 
industrial suitability of our work along similar lines. 

1 . Formal methods must not detract from the accom- 
plishments achieved by current methods 

2. Formal methods must augment current methods so 
as to permit industry to build “better’’ software 

3. Formal methods must be consistent with those cur- 
rent methods with which they must be integrated 

4. They must be compatible with the tools and tech- 
niques that are currently in use 

These criteria emphasise the need to develop formal 
methods for the types of practical tools and notations 
used in industry and also for formal methods to com- 
plement and not preclude existing practices. It is the 
authors' opinion that the work described in this paper 
has gone some way to satisfying these criteria, although 
admittedly for a particular domain and set of V&V ac- 
tivities. This was accomplished by basing the formal 

s The final validation of the system will tell whether the require 
merits indeed improved or whether errors were instead being intro- 
duced into areas not covered by the healthiness conditions. 



analysis and test case generation activities on an auto- 
matically generated formal representation of the intu- 
itive requirements specifications, written using existing 
modelling tools. In addition, the activities performed 
here complement methods already in use such as review 
and animation. As such they can be seen as natural ex- 
tensions to the existing modelling process. 

Formal specifications are typically very sensitive to 
change. However, due to automation, the formal spec- 
ifications can be re-generated and verified whenever 
a change in the requirements occurred, at little extra 
cost. The intuitive engineering requirements remained 
the first class citizens of the process and the standard 
interface to the engineers. The ongoing extensions to 
CADi Z to provide a ‘silent’ interface via an API will 
allow modelling environments such as Statemate to ex- 
ploit an intermediate formal representation of the re- 
quirements to perform checks and generate tests while 
hiding the details of the analysis from the engineer. This 
would further encourage an iterative development of the 
requirements (i.e. do not pass onto the coding phase un- 
til the requirements have been properly validated) and 
increase the efficiency of the test generation process. 

7. Conclusions and Future Work 

In this paper we described our experiences in inte- 
grating formal methods into an industrial software de- 
velopment process. Intuitive engineering notations were 
translated into intermediate formal specifications which 
formed the basis of automated proof and test case gener- 
ation activities. The high level of automation was made 
possible by restricting the work to a particular domain 
(discrete engine control requirements) and a tight sub- 
set of an otherwise highly expressive formal notation 
(Z). The automated analysis and tests allowed a signifi- 
cant amount of errors to be detected earlier than would 
have been possible had a manual, ad-hoc approach been 
taken. 

The findings support other work [5, 13, 1] that has 
similarly used formal semantics of engineering nota- 
tions to facilitate an effective approach to verification. 
The work presented here contributes to this field by 
showing that general purpose formal analysis tools such 
as CADiZ and SMV can be used to support automated 
analysis and test generation based on different engineer- 
ing notations given a suitable translation from the nota- 
tions to a formal specification. 

In developing these techniques we have identified the 
following generic process for applying fotmal methods 
to engineering notations for automated V&V. 

1. Use intuitive Engineering notations with fixed 
semantics: Record and maintain the requirements 


specifications in notations most suitable for the do- 
main and whose semantics can be formally speci- 
fied. 

2. Couch healthiness conditions as mathematical 
constraints: Identify “healthiness properties” that 
should be common to all specifications e.g. com- 
pleteness and determinism. Based on the formal 
semantics of the notations, couch these properties 
as mathematical constraints. Automate the transla- 
tion if possible. 

3. Formally specify the behaviour under test: De- 
fine a translation between the original notation and 
a formal specification of the properties under test 
based on the formal semantics. Automate the trans- 
lation if possible. 

4. Exploit existing tool-support: Apply a combina- 
tion of automated proof, model checking and con- 
straint solving to analyse the healthiness properties, 
to generate test specifications and to generate test 
data. 

5. Complement the formal specification and tests 
with informal text: To aid the review and docu- 
mentation of the analysis and test results, informal 
text descriptions should be generated and main- 
tained to describe the formal specification of the 
healthiness properties and tests. 

Ongoing work aims to increase the level of automa- 
tion and integration of the formal techniques into exist- 
ing specification modelling environments with the de- 
velopment of a CADiZ API. In addition to this, we also 
hope to expand the generic process and the toolset to 
cover more areas of the verification process. In par- 
ticular, the refinement of the intermediate fotmal spec- 
ification into program annotations that can be used to 
discharge correctness proofs on the code and the auto- 
matic efficient sequencing of test cases to reduce the 
amount of effort required to physically tun the generated 
tests. Other work will concentrate on developing further 
the constraint solving abilities of the CADiZ theorem 
proven This will allow a wider range of specifications 
and properties to be automatically verified than the cur- 
rent system. 
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Abstract 

We describe an approach to integrating the Z speci- 
fication notation into Cleanroom-style specification and 
verification. In a previous attempt, a group at IBM used 
formal refinement of the Z in their development. They 
concluded that this was not cost-effective in a commer- 
cial environment, and the attempt was not judged suc- 
cessful. The current approach avoids formal refinement, 
and instead begins by converting the Z to a fully con- 
structive form, expressing all state changes using an 
assignment notation. The development then proceeds 
in Cleanroom style, with sections of the Z specifica- 
tion simply distributed among the program components 
to serve as their specifications. In a pilot project, this 
approach was found to work quite well, with develop- 
ment proceeding smoothly and predictably as normally 
expected with Cleanroom methods. 


1 History of the problem 

In the early 1990s, a group of technical staff at the 
IBM laboratory at Hursley Park (near Winchester, Eng- 
land) attempted to integrate two software engineering 
technologies which IBM had previously used separately 
with considerable success: the Z specification notation 
and the Cleanroom method. 

The Z notation [15] [6] [13] [17] [18] is based on set 
theory and other basic elements of discrete mathematics, 
and incorporates novel structuring constructs (schemas 
and the schema calculus). Z technology also includes 
methods for the formal refinement of specifications into 
designs and code. 

The core of the Cleanroom method [10] [8] [16] 
is formal or sernifonnal specification, and correspond- 
ing verification done by a development group in review 
meetings. Other elements of the method include no- 
tations and techniques for stepwise refinement, testing 
based on expected usage patterns, statistical analysis of 
test results to predict product quality, and incremental 


development. 

IBM had had considerable experience with both tech- 
nologies. The Cleanroom method was developed largely 
at IBM, by Har lan Mills and his colleagues in the Fed- 
eral Systems Division. By the time of the Hursley ex- 
periment, it had been used successfully on a number 
of industrial-sized projects at IBM and elsewhere. The 
results were striking: very low levels of defects in the 
products, with no net loss and often a net gain in pro- 
ductivity [8] [3], 

IBM had just finished a substantial development 
project at Hursley using Z, in collaboration with its de- 
velopers at Oxford University [5], The project was a 
major new release of the CICS transaction processing 
system: 268,000 lines of new and modified code, of 
which 37,000 lines were specified and designed using 
Z and another 1 1 ,000 lines were partially specified in Z. 
For the parts produced using Z, IBM reported a higher 
percentage of defects eliminated early in the develop- 
ment, a lower level of defects in the final product, and 
an estimated 9% reduction in development costs. IBM 
and Oxford were jointly given the Queen’s Award for 
Technological Achievement for 1992 on the basis of this 
work. 

The CICS group at Hursley hoped that Z and Clean- 
room methods could be used together, and would com- 
plement each other to produce products of even higher 
quality than with either separately. The approach that 
they took was to write specifications in Z initially; to 
proceed with formal refinement steps as normally done 
in Z; to write the correctness criteria for these refine- 
ments as mathematical theorems; and to prove these the- 
orems in review meetings, as normally done in Clean- 
room. 

Hie experiment was not judged a success. In partic- 
ular, the group found it too hard to do the formal refine- 
ment from Z into code. The postmortem [12] concluded 
that “it is not cost-effective in a commercial software 
environment to do even semi-formal refinement without 
machine assistance” (which was not available). 

Despite this discouraging result, we felt that there 



was much to be gained if Z and Cleanroom methods 
could be integrated successfully. In the following, we 
describe a quite different approach. We avoid formal 
refinement in Z altogether, and instead begin by trans- 
lating Z specifications into a form that more closely re- 
sembles Cleanroom-style specifications. From there, the 
development proceeds in Cleanroom style, but retaining 
fragments of Z notation where appropriate. We found 
that, using this approach, the Z notation can complement 
Cleanroom methods quite effectively. 

2 Z and Cleanroom specification styles 

The Z notation is well suited to expressing the spec- 
ification of a system as a whole, or of major parts of 
a system. It provides a great deal of useful mathemat- 
ical vocabulary, and the vocabulary of discrete mathe- 
matics in particular, which can be used very effectively 
to specify aspects of an information-processing system 
at a high level. Furthermore, it provides the schema 
notation and the schema calculus, by means of which 
many different aspects of a specification, each perhaps 
derived from a different requirement of the system, can 
be expressed separately and then combined into a single 
specification. 

The Cleanroom method, on the other hand, provides 
relatively little built-in notation. Indeed, one of its 
strengths is that many kinds of notation, from a wide 
variety of domains and at many levels of formality, can 
be imported into it and used in its specifications. What it 
does provide is, in particular, a straightforward method 
of placing specifications on the lower-level components 
of a program, down to the level of the control construct 
or statement, and verifying that these components sat- 
isfy their specifications. 

It would seem to be a natural idea, then, to begin 
by writing the top-level specification of a system using 
Z, and then to proceed with the development in Clean- 
room fashion, distributing the Z specification among 
the program components and verifying those compo- 
nents against the specification fragments using Clean- 
room protocols in review meetings. 

However, there is a gap that must be bridged before 
the Z notation can be incorporated into Cleamoom-style 
specifications. This is because there are fundamental 
differences in the styles of the specifications of Z and 
Cleanroom. 

The Z notation is based on predicates, which express 
preconditions and postconditions on operations, invari- 
ants on data, and other assertions and constraints on the 
data objects and inputs and outputs of a system, hi par- 
ticular, the specification of an operation defines a rela- 
tion among inputs, outputs, previous values of state vari- 


ables, and new values of those variables. 

A fundamental property of Z is that such specifica- 
tions may be nonconstructive: they may express prop- 
erties that outputs and new values of variables must sat- 
isfy, without giving any clue as to how these values can 
be calculated from inputs and previous values of vari- 
ables. In fact, specifications may even be nondetermin- 
istic: they may not constrain each output and updated 
variable to a unique value. 

Here is an example which is both nonconstructive 
and nondeterministic, from the specification of a text- 
processing system: [6, p. 172]: 

[CHAR] 

TEXT == seq CHAR 

Forma t 

t, t' : TEXT 

words t' = words t 

Ml : ran (lines t') • #/ < width 


In the specification of an operation in Z, the name of 
a state variable is “decorated” with a ' symbol to refer 
to its new value; the undecorated variable name refers 
to its previous value. (Input variables are decorated with 
? and output variables with !.) Titus, this schema says 
that a Format operation leaves the sequence of words 
in t unchanged and that each line of 1 after the opera- 
tion must be no longer than width (the functions words 
and lines and the constant width are defined elsewhere). 
The specification says nothing about how to achieve this 
result and, in fact, there will usually be many ways of 
dividing t into lines that will satisfy this specification. 

Z practitioners see the ability to write nonconstruc- 
tive and nondeterministic specifications as an advantage: 

Non-deterministic operations are important 
because they sometimes allow specifications 
to be made simpler and more abstract [15, 
p. 131], 

Nonconstructive specifications achieve ex- 
pressivity and brevity at the expense of exe- 
cutability . . . they leave the programmer free 
to choose among different implementation 
strategies [6, p. 38]. 

In the Cleanroom method, on the other hand, the gen- 
eral rale is that specifications are both deterministic and 
constructive. Specifications are written in the “func- 
tional” style [9], in which each operation, control con- 
struct and statement in a program is viewed as comput- 
ing a function on the program’s state: 

X:=f(X) 



Here X is a state vector that encompasses all of the 
program’s state variables, including its input and output 
streams. Specifications are written in the form of in- 
tended functions which explicitly give values for every 
state variable which changes value. The usual notation 
is the concurrent assignment, such as the following: 

[ sum , i, trend := 

sum + i + 1, (sum + «[/'])/(/' + 1) ] 

A variant is the conditional concurrent assignment, 
which specifies a state change by cases, such as the fol- 
lowing: 

[ i > 0 —¥ trend ~ surnji 
| i = 0 —¥ sum, trend := 0, trend o ] 

Each case has a precondition and a concurrent assign- 
ment which is the state change to be performed when the 
precondition is satisfied; die computation is undefined 
whenever no precondition is satisfied. 

The usual situation is that the preconditions of a con- 
ditional concurrent assignments are mutually exclusive 
(there is no state in which any two are bodi true) and 
that the right-hand side of each concurrent assignment 
contains only single-valued expressions which are obvi- 
ously computable, hi diis case, the specification is deter- 
ministic and constructive. Exceptions are occasionally 
made, and occasionally a specifier will depart from this 
notation entirely. However, the rest of the Cleanroom 
method, and the verification in particular, will usually 
proceed more smoothly if the above conventions are fol- 
lowed. One reason for this is that a common manipula- 
tion in verification is to substitute the result of a compu- 
tation into the specification of a following computation 
and then simplify. 

3 The transition from Z to Cleanroom 

The first step in our adaption of a Z specification to 
Cleanroom-style development and verification, then, is 
to transform the Z into a deterministic and constructive 
specification, so that it can be expressed using the in- 
tended functions required by the Cleanroom method. It 
might seem that this would be a nontrivial task, requir- 
ing a great deal of effort and introducing many opportu- 
nities to make mistakes that will jeopardize the success 
of the project. 

However, in our' experience thus far, we find that the 
job is usually not as hard as one might think. This is 
largely because many parts of typical Z specifications 
are already deterministic and constructive. In particular, 
we find that many Z predicates are of the fonn 


or 

P A i’i = e\ A v ’2 = e -2 A . . . 

or 

(Pi A vn = en A v’i2 = ei2 A . . .) V 
(P 2 A V ’21 = £"21 A V ’22 = £”22 A . . .) V . . . 

where each v is a changed state variable or an output 
variable (i.e., an variable decorated with ' or !) and such 
variables do not occur in any P or e, and where (in the 
third form) the P, are mutually exclusive. Such pred- 
icates define computations that are clearly both deter- 
ministic and constructive, assuming that each P and e is 
single -valued and there is an obvious way to compute 
it. Furthermore, it is trivially easy to rewrite any such 
predicate in conditional-concurrent-assignment form. In 
fact, they are essentially in that form already, except for 
the symbols used. 

Fortunately, such forms are natural to use in many 
situations in Z specifications, and Z users seem to use 
them rather commonly. In 28 case studies presented in 
six prominent Z books [15, ch. 1] [4, parts B-D] [6, 
ch. 16-25] [13, ch. 8] [17, ch. 15 and 20-23] [18, ap- 
pendix A], over 67% of the 353 schemas which imply 
state changes or output are already in one of the above 
forms, once the schemas that are defined by including 
or combining other schemas are expanded out into their 
full forms. Another 6% contain instances of (for exam- 
ple) the new value of one variable being defined in terms 
of the new value of another, in contexts like 

a' =f(a) A 
b' = g(a') 

in which the departure from the above forms can eas- 
ily be eliminated by an obvious substitution. Again, the 
translation to conditional-concurrent-assignment form is 
straightforward. 

We could proceed, then, by translating all of the 
specifications of operations directly from Z predicates 
to conditional concurrent assignments, routinely in the 
easy cases and using more complex transformations 
in the other cases. However, to make the transition 
smoother, we devised an intermediate fonn which com- 
bines characteristics of both notations. It is very much 
like standard Z — in fact, it can be considered a non- 
standard dialect of Z — except that all state changes are 
specified explicitly and constructively. 

Here are the principal differences between this nota- 
tion and standard Z. 

• State changes are written in the fonn 


Vi = e\ A v 2 = e 2 A . . . 


x:=E 



This is equivalent to the standard Z 


f a b := E 


x 1 =E 

but the change in notation emphasizes the explicit, 
constructive definition of the state change. The 
same assignment notation is used to specify the 
computation of outputs. 

• Every change to a state component is specified in 
tins way; it is implied that no other state compo- 
nent changes its value. With this convention, all 
assertions of the form 

y =x 

are omitted as redundant from schemas that specify 
state changes. 

There are no implicit changes to one state com- 
ponent induced by changes to another state com- 
ponent and constraints between them. All state 
changes are written out explicitly. 

• In the same spirit, where it is asserted that part of a 
structured state component is changed, it is implicit 
that the rest of the component remains unchanged. 
In particular, where the state component is a map- 
ping (in Z represented as a function), a change to its 
value on one element of its domain can be written 
in the form 

f a E 

If this is the only change to / that is specified in 
the schema in which this appears, it is implied that 
/ remains unchanged otherwise, and the above is 
equivalent to the standard Z 

f =f®{a^E} 

where © is the “override” operator. 

More than one change to the same function can be 
specified: 

/ a\ := £1 A f a 2 := E 2 
means 

f =/ © { 0 \ i-f Ei, a 2 t-T E 2 } 

which, of course, is well-defined (i.e.,/' is still a 
function) only if a \ / a 2 or E\ = E 2 . 

A change to a (curried ) function of two arguments 
can be written as 


which (if no other changes to/ are specified in the 
schema in which this appears) is equivalent to 

/'=/©{a^((fa)©{h^£})} 

and so on for functions of more arguments. 

• Since the syntax x := E is really a predicate, it can 
appear anywhere a predicate can appear, such as 
within file scope of a quantifier. An example is 

Vx : T | x € S • 
f x:= a 

which means 

f = f (B {x : T \ x e S • x a} 

• The symbols A and E are now superfluous in most 
places and may be omitted. 

• All computations of new states and outputs appear 
only in contexts which are unconditional, or in con- 
ditional structures (using V and A) with mutually 
exclusive conditions. 

Many of these notation conventions are similar to 
constructs in the notation of the B method [19], although 
that notation is more restrictive than AZ in a number of 
ways. 

Since state changes are specified hi the form of as- 
signments, we tentatively call this variant of the Z nota- 
tion “Assignment Z”, or AZ. (We considered the name 
“Constructive Z”, but this name is already in use with a 
somewhat different meaning [11].) We present AZ not 
as another formal specification notation, but merely as 
an informally-defined intermediate form between Z and 
conditional concurrent assignments. 

Where the Z specifications are not already construc- 
tive, we transform them into a constructive form as we 
rewrite them in AZ notation. For example, we would 
rewrite 

Pop 

stack, stack' : seq Item 
x! : Item 

stack = (x!) ^ stack' 


as 



Pop 

stack : seq Item 
x! : Item 

x! := head stack 
stack := tail stack 


Often, as here, making a state change constructive is 
rather easy, but it can require considerable manipulation. 

There is sometimes more than one way to express 
the constructive version, and whatever choice is made 
will usually suggest a design or implementation pos- 
sibility more strongly than the nonconstructive version 
did. Similarly, where the specification is nondetermin- 
istic, making it deterministic typically involves either 
making arbitrary choices as to the result that is speci- 
fied, or making choices influenced by design or imple- 
mentation considerations. An example is an allocation 
of a resource from a set of numbered resources: 

Allocate 

free : FN 
allocated' : N 

allocated' € free 
free' =free \ allocated' 


(Here F means “finite set of” and N denotes the natu- 
ral numbers.) As we convert this to AZ form, we might 
make it deterministic by arbitrarily choosing the free re- 
source with the minimum number: 

Allocate 

free : FN 
allocated : N 

allocated := min free 
free :=free \ {min free} 


Another way of resolving the nondeterminism would 
be to define free to be a sequence rather than a set, and 
choosing the first element of the sequence every tune: 

Allocate 

free : seqN 
allocated : N 

allocated := head free 
free := tail free 


Clearly, tins version encourages a different implementa- 
tion. It is important to realize that the transformations 
that we perform to make the specification constructive 
and deterministic are not just changes in notation, but 


are true development steps, and may involve nontrivial 
and significant design decisions. 

It is probably not necessary to be too dogmatic about 
removing all nonconstructive and nondetenninistic as- 
pects of file specification at this stage. Consider this ex- 
ample: 

DisplayPeople 

knownPeople : F PERSON 
people ! : ¥ PERSON 

people ! = knownPeople 


This is reasonable Z, but of course if a set is displayed 
as an output, it must be displayed in some order. A pos- 
sible conversion to AZ might be: 

DisplayPeople 

knownPeople : F PERSON 
people ! : seq PERSON 

people ! = alphabet! calSort knownPeople 


where alphabeticalSort denotes sorting by name in 
phone-book order. One might object that tins is still both 
nonconstructive and nondetenninistic, since it does not 
suggest how the sorting is to be done, and it may al- 
low more than one outcome if more than one person can 
have the same name. But any other way of writing this 
specification is likely to be more complicated and less 
satisfactory. Furthermore, it is obvious that any compe- 
tent programmer can create an implementation that will 
satisfy it. In such situations the pragmatic thing to do 
may be to allow specifications such as this one, although 
we should do so only after careful consideration. 

4 A pilot project 

To try out the techniques presented above, we at- 
tempted use them on a development project of modest 
size. As it happened, we had a project that we were al- 
ready planning to undertake. 

The project was to develop a “rehearsal scheduler’s 
assistant”: a program to help with the planning and 
scheduling of the rehearsals and other preparation for 
a theatrical production. The central job to be done is to 
manage the interacting schedules of many activities and 
many people. We had a real client, Doug Dunston, the 
faculty member in charge of the music program in our 
college. (The project is described in somewhat fiction- 
alized form in section 1 1 . 3 of [ 1 6] .) 

The first step of the development, after discussing re- 
quirements with the client, was to prepare a specification 



in standard Z. As is common practice with Z, the speci- 
fication took the form of a document, with sections of Z 
interspersed with explanatory text in English. The spec- 
ification contained 43 schemas, and 16 other Z sections 
containing definitions of various kinds. 

The specification document contained one other im- 
portant specification notation: color pictures of the 
screens and other components of the graphical user in- 
terface (GUI). Here is an example: 



mm&tm&ay earrcfstPersem \ 


Schedule of 

ttafns eusrentPsir$t*f$i 

John Shipman 


"Stewpot'". 

Can lead chorus rehearsals when necessary. 


SckvdiikSiki'ifir; 

O normal d<3ts . 

(§) week of [ March 19~ 


I mvdape sat \ 

Mem: 

□ view or change activities j 
1 change schedule 

□ view conflicts 

[ delete this person 


| j activities 
IHI other obligations 
H conflict 


We used pictures like these to include in the specifi- 
cation a general idea of what the GUI would look like. 
However, we adopted the convention that the pictures 
would represent only an approximation to the appear- 
ance of the interface, which might vary somewhat ac- 
cording to the eventual implementation. Colors and di- 
mensions (for example) might be slightly different from 
the way they appear in the pictures, and there might 
be implementation-dependent features not shown in the 
pictures, such as additional ways to move from one 
screen to another. 

On the other hand, some aspects of the pictures are 
quite specific. In particular, some of the elements of 
each picture are tied to the Z specifications through la- 
beling conventions. In the picture, an annotation of 
the form someName: (which appears in a distinguished 
color, magenta, when the specification is printed or dis- 
played in color) is not to appear in the actual GUI as 
displayed, but indicates that the corresponding part of 
the GUI corresponds to the construct of the same name 


in file Z specification. If there might be any doubt as to 
what part of the display is being referred to, a box of the 
same color is drawn around the relevant part; again, tins 
will not actually appear in the GUI. 

Here is the Z schema that corresponds to the above 
picture: 

PersonScreen 

PersonData 

ScheduleSelector 

PersonScheduleDisplay 

Menu[SCREEN] 

screen = personScreen 
preselected ! := normal 
date = today 

menuChoices\ := 

{ editPersonScreen i-j 

“view or change activities”, 
personScheduleScreen i-4 

“change schedule”, 
shoxvConflictsScreen i-4 
“view conflicts”, 
deletePersonScreen i-4 

“delete tins person” } 
screen := chosenlteml 

The annotation screen ~ personScreen in the picture 
indicates that screen has the value personScreen when 
what the user sees is the screen shown in the picture. 
The variables date and preselected ! are defined in the 
schema ScheduleSelector: preselected ! defines which of 
tlie two selector buttons is initially shown as selected. 
Whenever a schema defines a GUI component, we de- 
fine informally in the accompanying text how the Z com- 
ponents relate to what the user sees and can manipulate. 

We adopted several other conventions to reduce the 
amount of repetitive detail in the specification. For ex- 
ample, in many places in the GUI there is a box in which 
tlie user can fill in or edit a value. Wherever a picture 
contains such a box labeled with the name (for example) 
x, and x is a variable of type T, we treat that annotation 
as implicitly introducing a Z schema of the fonn 

Edit^x 

displayed- jc! : TEXT 
entered, jr? : TEXT 
x:T 

displayed^. := TtoTEXT x 
x := TEXTtoT entered xl 

where TtoTEXT and TEXTtoT are appropriate conver- 
sion functions. Tlie box labeled date: is an example 



of this; the schema personScreen also specifies that the 
value initially displayed for date is today’s date. 

The specification document, then, contains English 
text, Z notation, and pictures, all interrelated. It should 
be apparent that some parts of the specification are for- 
mal and other parts are quite informal. In all, the docu- 
ment is 42 pages long. 

The next step, after meeting again with the client to 
discuss that specification and obtain his approval, was 
to prepare another version of the document in which the 
parts of the Z sections were rewritten in AZ form. This 
turned out to be quite easy in most places, especially 
since most of the state changes were specified in such a 
way that the translation was trivial, as discussed in the 
previous section. In many cases, the resulting specifica- 
tions turned out to be considerably simpler than the orig- 
inal, largely because of the AZ convention for express- 
ing changes to components of structured objects. Forex- 
ample, the specification used curried functions like the 
following in many key places: 

SCHEDULESTATUS ::= 

free \ booked \ otherObligations \ conflict 
DAYSCHEDULE == 

TIME -4 SCHEDULESTATUS 
WEEKSCHEDULE == 

DAYOFWEEK -> DAYSCHEDULE 

NormalScheduIes 

People 

normalSchednle : 

PERSON WEEKSCHEDULE 


This was a natural way of constructing 
normalSchednle, especially since we sometimes 
wanted to refer to the whole weekly schedule of a 
person, sometimes for that schedule on a particular day, 
and sometimes to that schedule at a particular time. But 
then specifications of state changes like the following 
became complex and tedious: 

normalSchednle' = normalSchednle © 

{ cnrrentPerson h-» 

(normalSchednle cnrrentPerson ) © 

{ day i — y 

(normalSchednle cnrrentPerson day) © 
{ t e possibleTimes day \ 
from < t < to • 

1 1 — y selected '? } } } 

The AZ form of this is much more straightforward: 


V t e possibleTimes day \ from < t < to • 

normalSchednle cnrrentPerson day t 
:= selected ? 

In determining what needed to be rewritten to make 
it constructive, we were guided by pragmatic considera- 
tions. For example, the original specification contained 
a number of state changes specified using set compre- 
hensions, in forms such as 

result {a £ S \ P(a )} 

But in each such case, S was a finite set and so, in 
principle at least, the set of its elements satisfying P 
could be constructed by a simple-minded enumeration 
of the set, testing each element. Indeed, for this reason a 
mathematician would probably consider such an expres- 
sion quite constructive, and we judged all such specifi- 
cations to be “constructive enough” for our purposes. In 
fact, in file implementation, each such set turned out to 
be reasonably small, and so this is exactly how almost 
eveiy such state change was actually implemented. 

For a number of reasons, including portability (the 
program was to be developed on our Linux machines 
but would eventually run on Dr. Dunston’s Macintosh), 
we chose the Python programming language and the Tk- 
inter GUI library for the implementation. 

We found it easy to implement many parts of the 
AZ specification using Python constructs, in ways that 
so obviously matched the specification that verifica- 
tion was hardly necessary. This was especially true of 
state changes that called for modifying values of func- 
tions. We implemented the function normalSchednle, 
for example, as a dictionary indexed by Person and 
Activity objects, containing lists indexed by numbers 
representing days of the week, where those lists con- 
tained dictionaries indexed by Time objects and contain- 
ing ScheduleStatus objects. Titus, for example, the im- 
plementation of the state change specified by 

V t € possibleTimes day \ from < t < to • 

normalSchednle cnrrentPerson day t 
selected ? 

turned out to be simply 

for t in possibleTimes (day) : 
if fromTime <= t < toTime : 

normalSchedule [currentPerson] \ 
[day] [t] \ 

= selected 

which is essentially identical to the specification. 

We used one other significant piece of software en- 
gineering technology in the project: a form of “literate 



programming” [7], This means that the program is pre- 
pared and presented in the form of a document, with 
explanatory text accompanying each section of program 
code. Thus the program and its documentation are in- 
tegrated, and stored in a single hie. There are software 
tools that process that hie either to ship out and order 
the code sections for compilation and execution, or to 
format the document for viewing or printing. 

In the usual kind of literate programming, the code 
fragments may appear' in the document in any order, but 
the author must use markup commands to define their 
ordering and nested structure in the hnal program. We 
adopted a much more “lightweight” approach, in winch 
the code fragments appear in hie program in the same or- 
der in which they are presented in die document. This is 
reasonable with Python, in which die order of elements 
in a program is relatively unconstrained. And it means 
that die program that strips out die code fragments for 
execution does not need to do any reordering, which 
made it a very simple program. Even more important, 
it means tiiat die programmer does not need to include 
markup to shucture die program fragments. In fact, the 
only extra markup necessary is a pair of commands de- 
fined in the markup language ( L A TgX in our case) to mark 
the beginning and end of a code fragment. 

With veiy little extra effort, then, we were able to 
maintain the code and a description of it as a readable 
document. In many places we also included sections of 
Z and pictures of the GUI, cut-and-pasted from die spec- 
ification documents. The result is a document very simi- 
lar to those documents in style and appearance, but with 
code sections added. Each code section is accompanied 
by commentary and, in many cases, the Z and pictorial 
specifications from which the code was derived. 

In many places we also extracted fragments of Z from 
the specification and incorporated them into intended 
functions in the code fragments. Here is an example: 

I vl 

def emptyDaySchedule ( d ) : 

[ returned value := a dictionaiy 

{ t. € possibleTimes(d) • ( h> free) } ] 
result = { } 

for t in possibleTimes (d) : 
result [t] = free 
return result 


By the way, the annotation “V” in the corner of the 
box indicates that this section of code has been verified. 
An annotation “VT” would indicate that it had also been 
tested. We used such annotations to keep track of the 


status of each fragment directly in the program docu- 
ment during the development, and we found this very 
helpful. 

We did not follow Z protocols for formal refinement 
at all. The implementation was constructed using ordi- 
nary programming skills, as well as Cleanroom-based 
methods in which intended functions are implemented 
in a stepwise manner in terms of code and lower-level 
intended functions [16, ch. 5], We constantly used the 
structure of the Z specification as a guide, and this made 
many parts of the implementation almost trivial to con- 
struct. 

We verified both the translation of the Z to AZ, 
and the program code developed from the AZ. Unfor- 
tunately, we were unable to adhere strictly to Clean- 
room methods in doing tins. Cleanroom is inherently 
a group process; in particular, verification is done in 
review meetings, with the author and colleagues dis- 
cussing each correctness criterion and examining the 
program for other aspects of quality. The goal is to dis- 
cover and eliminate as many defects as possible while 
attempting the verification. Normally this requires a 
group of at least three people, since each person often 
notices defects that the others miss. 

But only one other person trained in Cleanroom 
methods was available at the time, and the amount of 
time that he had available was quite limited. There- 
fore, parts of the program were verified in a two-person 
group, and some parts were done strictly as a solo effort. 
We found that verification under these circumstances 
was far less reliable than normally expected with Clean- 
room methods, which typically achieve a level of defects 
of three per thousand lines of code or better before first 
execution [8] [3], 

To add to our difficulties, we were somewhat unfa- 
miliar with the Python language and the Tkinter library, 
and made a number of minor mistakes in usage, espe- 
cially early in the project. Since Python is an interpreted 
language, the mistakes that escaped our notice during 
verification were not caught in compilation, but in first 
execution. 

To attempt to compensate, we eventually developed 
an alternate protocol. The project plan called for the pro- 
gram to be developed in rather substantial increments, as 
is normal with the Cleanroom method. We divided each 
of these into a number of very small increments, each 
adding perhaps only one simple new feature to the pro- 
gram; these increments ranged in size from about thirty 
to two hundred new and changed lines. 

After each of these increments was coded, we in- 
spected it several tunes, using a checklist and checking 
different aspects each time. We checked such things as 
points of syntax and usage which had caused us prob- 



lems before, matching of each function and method call 
against its definition (comparing both intended functions 
and number and types of parameters), and correspon- 
dence of intended functions with the Z in the specifi- 
cation document. Finally we inspected for correctness 
of each section of code with its intended functions, hi 
some cases, as in the normalSchedule example above, 
we judged the code obviously correct “by inspection”; 
in other cases we carried through more detailed correct- 
ness arguments, mentally or on paper [16]. We caught 
and eliminated many defects by means of these inspec- 
tions, about four defects per hundred lines on average. 

Each increment was then integrated into the program; 
thus we were, in effect, “growing” the program gradu- 
ally, as advocated by Brooks [1, p. 18], At each integra- 
tion step we ran a few cursory tests to execute each new 
piece of code for the first time, and many more defects 
showed up immediately. The defect density on first exe- 
cution was about five per hundred lines on average, not 
nearly as good as normally expected with Cleanroom 
methods. Tlius, our one-person inspection protocol does 
not come close to competing with a full Cleanroom-style 
verification review by this measure. 

Fortunately, this had little effect on the effectiveness 
of the development! Almost all of the defects that sur- 
vived file inspections were caught on first execution and 
were simple oversights: typographical errors, mistakes 
in punctuation, mistakes in names of variables, omitted 
initialization, and the like. Each took only a few minutes 
to track down and fix. There were no deep algorithm 
flaws, no subtle bugs which would cause malfunctions 
only rarely, and no places in which we had implemented 
algorithms that would do something quite different from 
what was specified. This is typical of what normally 
happens in a Cleamoom-style development: the really 
nasty bugs are the ones that specification and verification 
seem to be most effective at preventing or eliminating. 

Most important for the subject of this paper, the entir e 
development went very smoothly. At no time did we feel 
that the mixture of notation was a hindrance or added ex- 
cessive complexity to the process. On the contrary, we 
felt that it was definitely helpful to have a Z specification 
to use a a basis for the development, and that specifying 
the program using the vocabulary of discrete mathemat- 
ics right from the beginning probably made the design 
cleaner than it would otherwise have been. We also felt 
that using Cleamoom-style intended functions and step- 
wise refinement definitely contributed to the quality of 
the product, as did inspections, imperfect as the latter 
were. These are subjective judgments for the most part, 
of course, but we think they are justified. 

At the time of writing, the third of the five major in- 
crements called for in the project plan has been com- 


pleted, resulting in 1409 nonblank, non-comment lines 
of code in file Python language. (We estimate that sev- 
eral times as many lines would have been needed in a 
lower-level language such as C or Java.) We found only 
five defects in further testing; this means that file defect 
density that we obtained after inspection and first test 
during integration is comparable to the defect density 
normally obtained after verification in Cleanroom. 

Dr. Dunston has begun to use the program experi- 
mentally, and intends to put it into full production use 
for his next musical comedy. By that time the remain- 
ing increments will be constructed and installed. Mean- 
while, we have begun to use the program in our own 
work, to help schedule the activities of the staff of an in- 
troductory computer science course (lecturers, teaching 
assistants, tutors and graders) around all of their other 
obligations. The program has been quite helpful with 
this. As of the tune of writing, no further defects have 
been found in the program. 

5 Conclusions 

We consider that the integration of Z and Cleanroom, 
as described above, was successful. We believe that the 
use of specification via pictures and of “lightweight” 
literate programming contributed to the success of the 
project as well. Results obtained from one project of 
this size are not conclusive, of course, but all indications 
are positive tlius far. 

We definitely intend to use similar combinations of 
technologies in future projects, and are eager to try them 
on substantially larger projects. Since Z and Cleanroom 
have been used separately on projects of substantial size 
with considerable success, we see no reason why the 
same should not be true when they are used together, 
but only actual experience will tell us with certainty. 

Beyond this, we believe that our results confirm and 
support several ideas already noted by other writers and 
researchers regarding the way to use formal methods 
most effectively. First, formal methods are not mono- 
lithic: it is quite possible to use some parts or aspects 
of a method without using all of the method. For exam- 
ple, it makes perfect sense to write specifications in Z 
even if one has no intention of using the accompanying 
methods for formal refinement, and doing this seems to 
be rather common among Z users. 

Similarly, it is perfectly reasonable to use more than 
one formal method or notation in a project, according to 
which is most suitable for each part of the project. A 
notable example of this was the development project for 
the CDIS air traffic control display system [2], which 
successfully used a variety of formal notations: VDM, 
VVSL, CSP and CCS, as well as data-flow diagrams and 



finite-state machines. 

Finally, full formality is not only not necessary to ob- 
tain the benefits of formal methods, but is frequently not 
even productive or cost-effective. In die postmortem to 
the Hursley experiment [12, p. 293], Mark Pleszkoch 
of die IBM Cleanroom Software Technology Center is 
quoted as saying: 

I believe that the key to applying Cleanroom 
in a cost-effective, highly productive maimer 
is to not force developers to go to a level of 
formality beyond dieir needs (and abilities), 
while at die same time not losing the bene- 
fits of precise documentation diat makes clear 
what each piece of code is designed to do. 

A number of odier writers have been expressing sim- 
ilar opinions in recent years (see, e.g., [14] and [2, 
pp. 74—75]). The general principle is that diere is an ap- 
propriate level of formality for every situation, and more 
rigor is not always better. If this is not yet the consensus 
of the formal methods community, perhaps it eventually 
will be. 

Acknowledgement: We are indebted to Steve Powell 
of IBM at Hursley for many thoughtful comments and 
suggestions. 
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Abstract. Over the last few years, several alternatives for adding mobility to Asynchronous Transfer Mode (ATM) 
signaling protocols have been presented in the literature. However, most of the current approaches for wireless 
mobile ATM (WmATM) network development include basically text and information flows. As a result of the 
complexity involved in handling mobility, communication and handoff procedures for WmATM networks, current 
approaches can lead to ambiguities, gaps, inconsistencies and undesirable interactions at the later stages of the 
development process where changes can be costly and provoke backward incompatibility. With these problems in 
mind, this work proposes a development approach that includes a technique called Use Case Maps (UCMs), and the 
following formal methods: Language of Temporal Ordering Specifications (LoTOS) and Message Sequence Charts 
(MSCs). UCMs are applied at the requirements capture and analysis stages, followed by LoTOS and MSCs at the 
design stage. Besides providing a better and precise description of the system at the early stages, our main goal is to 
combine these techniques and help to solve design problems like the ones mentioned above. As a case study, 
WmATM network procedures are specified using the proposed approach. 

Keywords. Causal Scenarios, Use Case Maps, Formal Techniques, Language of Temporal Ordering Specifications, 
Message Sequence Charts, Wireless Mobile ATM Networks. 

1. INTRODUCTION 

Although Formal Description Techniques (FDTs) have been successfully used to specify and validate 
protocols in different application domains achieving clear and concise specifications, most current 
development approaches for Wireless mobile ATM (WmATM) networks include basically text and 
information flows at the early stages. As a result of the complexity involved in handling mobility, 
communication and handoff procedures, these approaches can lead to ambiguities, gaps, inconsistencies 
and undesirable interactions at the later stages. 

FDTs, such as LoTOS [21], the Language of Temporal Ordering Specifications, and Message 
Sequence Charts (MSCs) [18], have not only shown resiliency in the usability, but also tool support and 
training have improved in the last 15 years [4] [12] [13], Even though LoTOS and MSCs can be used at 
different levels of abstraction, it requires precision on the description of action sequences and exchanged 
messages. Thus, these fomial techniques are more suitable to be applied at intermediate stages of the 
development process. In contrast, visual techniques such as Use Case Maps (UCMs) [8] [9] give to the 
designer capability to work with whatever amount of detail is available being appropriate for the early 
stages. 

In this context, we propose the application of UCMs, LoTOS, and MSCs at different stages of the 
system development process. UCMs are applied at the requirements capture and analysis stages, followed 
by LoTOS and MSCs at the design stage. The proposed approach is applied to the development of a 
prototype for WmATM networks. Mobility, communication and handoff procedures are firstly described 
with UCMs and, in conformance to that, formally specified and validated with LoTOS. MSC scenarios 
are automatically generated from the LoTOS specification in order to represent the results of the 
validation and facilitate the implementation of protocols. 

This paper is divided into 7 sections. An overview of the WmATM networks is given in Section 2. 
Section 3 illustrates the proposed development approach. A big picture of the relationship among 
mobility, communication and handoff procedures for WmATM networks are described with UCMs in 
Section 4. After that, the corresponding LoTOS specification is presented in Section 5. Section 6 shows 
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the generated MCSs scenarios and, last, Section 7 discusses our main contributions. Related works are 
also mentioned in Sections 4, 5 and 6. 

2. CASE STUDY: WIRELESS MOBILE ATM NETWORKS 

Asynchronous Transfer Mode (ATM) was developed in the 90s to support high-bandwidth multimedia 
applications and provide bandwidth on demand, traffic integration, cost effectiveness, as well as flexible 
data networking [23], Nowadays, ATM is viewed as a strong candidate to extend these services to 
portable systems using wireless technologies [1][28][30]. Accordingly, several alternatives for adding 
mobility to ATM signaling protocols have been presented in the literature [5] [6] [7] [10] [24] [31]. For 
example, [7] and [28] present WrnATM networks as a wireless extension of ATM networks with mobility 
and any modification in the existing ATM signaling protocols. On the contrary, [24], [30] and [31] 
believe that minimum challenges should be done in the ATM networks to support mobility and achieve a 
global WmATM network environment. In [5] and [6], the authors present two different signaling 
protocols to support both alternatives. 

2.1. A Typical WmATM Network Environment 

Figure 1 illustrates a possible environment that can support the concepts involved in designing a global 
WmATM network. The wireless service area is divided into cells and each cell is equipped with a base 
station transceiver (BST) that is responsible for the use of the allocated spectrum. A base station (BS) is 
responsible for a set of BSTs that are connected to the BS through wireless access ports. Several mobile 
stations (MSs) share the capacity of each BST. A wireless ATM network backbone is composed of 
WmATM switches attached through high-speed transmission links. Databases are responsible for keeping 
information about mobile users. The wireless backbone can communicate with the ATM network 
backbone using wired access ports. 

We choose a simplified wireless mobile ATM network as a case study, since it is representative of 
large and complex systems and touches upon common problems in the development process of these 
systems. The WmATM reference architecture considered in our work includes mobile stations, WmATM 
switches and databases. An ATM network composed of ATM switches and fixed stations is also described 
to allow the communication between fixed and mobile stations. Since we focus on signaling protocols for 
upper layers, base stations are not considered. Mobile stations communicate directly with WmATM 
switches and mobility occurs every time the mobile station changes a location area (represented by 
changing the WmATM switch). 



Figure 1 A Possible Wireless Mobile ATM Network Environment 
(adapted from Figures 2, 3 and 4 of [24][7] and [1], respectively) 

In the ATM fixed networks [17], there is no need for databases since each fixed station has a user’s 
identification that determines where the user is and how to route a call to the user. Our work focuses only 














on the specification and validation of connections between mobile users and between mobile and fixed 
users. 

During the development of the WrnATM network environment, each component of the reference 
architecUire is specified with its corresponding protocols related to mobility, communication and handoff. 
Informally, mobility management functions provides a secure environment for mobile users, updates 
location information and perform the user de-registration in an old location area when a mobile user 
roams and registers in a new location area. Communication management functions are used to establish, 
release and maintain calls between two mobile users, from mobile to fixed users, and from fixed to 
mobile users at their request. Meanwhile, handoff functions give to the mobile user freedom of motion 
beyond a wireless coverage area by maintaining the quality of a link whenever a user moves from one 
location to another. 

2.2. Current Development Approaches 

Several signaling protocols alternatives for wireless mobile ATM networks have been presented in the 
literature and their development approaches involve informal descriptions as text at the early stages 
followed by flow charts [7][31], state models [10], or information flows [5][6][24] as shown in Figure 2. 



When signaling protocol requirements are described only with text, they can lead to redundancies and 
become cumbersome to read, understand and manage at the later stages. An attempt to solve these 
problems is usually done following informal description by information flows (also known as sequence 
diagrams or message sequence charts). However, they are only necessary for detailed design, when design 
decisions about messages, parameters, data, and system components need to be taken. State models are 
also suitable for later stages, since they demand full precision during the definition of each state and 
underlying architecture. As a result, from the informality of the text to these formal models, a description 
gap can be identified that leads to protocol inconsistencies and undesirable interactions at the later stages. 
Even though flow charts are more adequate after informal descriptions to reduce this gap, they quickly 
become difficult to manage due to the increasingly complexity involved in the description of architecture 
and protocols of large systems such as WrnATM networks. Besides this, information flows and flow 
charts produce disjoint scenarios that can not be validated. Thus, completeness and consistency can only 
be checked at the implementation stage. 

3. THE PROPOSED DEVELOPMENT APPROACH 

In order to overcome the problems mentioned earlier, this work proposes the combination of techniques 
such as UCMs, LoTOS and MSCs in the system development process. The proposed approach splits this 
process into a number of steps, called stages, each of which produces a more detailed view of the system. 
By decomposing a system into manageable units, we are applying a strategy used by object- and function- 
oriented software community when dealing with the complexity of large systems [11], Besides this, we 
are adding rigor to the approach by using formal techniques. Figure 3 depicts the proposed development 
approach with requirements capture, analysis and design stages. Arrows show how these stages interact 
and represent the relation dependency on. Several development cycles represent the gradual and iterative 








characteristics of the approach. Since implementation and testing are not considered for our work, we 
omit these stages in the figure. 
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Figure 3 Proposed Development Approach 

The requirements capture stage is the first input for the development of a system. The elicitation of 
meaningful requirements identifies and documents what the system is supposed to do and which are the 
main functions to be described. Use cases are used for most software community to describe the sequence 
of events of an actor (an external agent) using a system to complete a process [19]. To avoid ambiguities 
caused by narrative documents such as simple text or even textual use cases, these informal descriptions 
are replaced by a requirements model developed with UCMs. Since the notation is informal and intuitive, 
it is suitable for the early stages when the user needs are described in a high-level of abstraction and 
designers are discussing about, visualizing and explaining the overall behavior of a system. For example, 
at the beginning, when organizational structure details are not available, this visual technique describes 
high-level scenarios in terms of causal relationships between responsibilities (called unbound UCMs). 
The stub notation is used to hide functions that are detailed at the later stages. 

Design decisions regarding which system component is responsible for a specific action, event or 
transaction are taken during the analysis stage. The functional behavior is further investigated and 
mapped to system components (part of the reference architecture). The analysis model is generated with 
bound UCMs. Detailed descriptions about what the system does are represented in terms of UCM 
notation: plug-ins , detailed responsibilities, detailed pre- and post-conditions. 

Even though UCMs are supported by a drawing tool (the UCM Navigator) [20] and by a user group 
[29], due to its informality, validation and verification techniques are not possible. Two formal methods 
are included at the design stage, LoTOS [21] and MSCs [18], to describe how system components 
communicate or interact in order to fulfill the analysis model. Details regarding data types, parameters 
and exchange messages are introduced in a design model (behavior and reference architecture are 
described with LoTOS) and successful and unsuccessful outcomes are shown in several MSCs ( scenario 
models). 

LoTOS specifications represent a system prototype by describing temporal relations with externally 
observable behavior. Abstract data types are also included in this formal technique. Details about LoTOS, 
standardized by ISO, can be found in [21], This LDT is supported by tools that offer ways of checking 
completeness and consistency. Lor instance, LOtos LAboratory (LOLA) is a set of tools developed by tire 
Department of Telecommunication Engineering (ETSIT) of the University of Madrid [22] that includes: a 
step-by-step executor, a tool for obtaining the labeled transition system, and a tool for testing. 

MSCs [18], standardized by ITU-T, describe interactions between system components. Each MSC 
represent exactly one scenario by focusing on the communication behavior of system components and 
their environment through message exchanges. We use MSCs to represent the results of the LoTOS 
validation and these scenarios are used as input to the implementation and testing stages. Recently, a 




Lotos2MSC Converter is being developed by Bernard Stepien [25] in order to generate MSCs directly 
from LoTOS traces. The first version is already available and applied to our work. 

As a case study, we iterative and gradually specify and validate a simplified WmATM network 
environment. The system behavior increases with designer and user needs. Each development cycle 
brings more details regarding new functional requirements as well as new system components. At the 
beginning, mobility management are described (development cycle 1), followed by communication and 
handoff functions (development cycle 2 and 3). Next sections present the description of the system 
functional behavior and reference architecture using our approach. 

4. WmATM DESCRIPTION WITH USE CASE MAPS 

This section presents the requirements capture and analysis stages of the proposed development approach 
depicted in Figure 3. These models are based on the description of WmATM signaling protocols 
presented in [5] [6] as well as on our experience with wireless network standards [3] [4], By focusing on 
the functional requirements with the UCM notation, firstly, it is possible to describe the whole scenario of 
how the simplified WmATM network environment works. The system is decomposed in the following 
functions: mobility (authentication, registration and de-registration), communication (connection 
establishment and disconnection) and handoff functions. These functions are gradually described in terms 
of sequential actions with unbound UCMs (the requirements model) followed by more details about the 
system behavior and the addition of the reference architecture with bound UCMs (the analysis model). 
We present the first development cycle related to mobility management functions. Scenarios related to the 
other functions as well as exceptions (such as network failure, lack of network resources, database failure 
and so on) are left to the next development cycles. 

4.1. Requirements Model: Unbound UCMs 

The whole behavior of the system and, consequently, the relationship among the functions mentioned 
earlier are better understood by following the UCM flows shown in Figure 4. Based on the root map, 
users and designers can discuss about early decisions regarding the sequence in which these functions are 
performed. This map describes the system behavior that starts when a pre-condition is triggered, for 
example, the user powers on a mobile station (filled circle labeled S). A stub (such as MM, HP and CM in 
the figure) identifies places where details are delayed to a sub-UCM, called plug-in. The stub notation is 
applied to our work not only to hide details, but also to decompose the system into small manageable 
units. In this paper, we focus on the MM Stub to show the development approach step-by-step. 
Communication management and handoff functions are not described for space limitation. 



Legend : 

S: Start (user powers on mobile station) 

CM: Communication Management Procedures 
HP: Handoff Procedures 
MM : Mobility Management Procedures 
[al] : [handoff inter-WmATM switches] 

[a2] : [mobility management functions] 

[a3] : [successful handoff] 

[a4] : [A handoff failure aborts MM and CM sub-maps] 
[a5] : [no communication is requested] 

[a6] : [communication is requested] 

[a7] : [(un)successful communication] 

El : endHP (user powers off mobile station) 

E2 : endHFA (a failure has occurred) 

E3: endCM (user powers off mobile station) 

E4: endMM (user powers off mobile station) 


Figure 4 WmATM Network Root Map: Unbound UCMs 



Tli is scenario ends with one or two of the following post-conditions: user powers off mobile station (bars 
labeled El, E3 and E4) or a handoff failure occurs (bar labeled E2). A route is a path that links an initial 
cause to a final effect. For example, <S, [a2], MM, E4> represents a route for registration followed by an 
user powers off event. The zig-zag notation ([a5] path) exists to describe exception paths, however, we 
propose its use also to describe synchronous interactions between stubs such as HP and CM (HP replaces 
CM in case of handoff failure). Direction arrows help designers to visualize the UCM flow as in the HP 
stub where an outgoing path returns to the same stub in order to trigger the plug-in. And-forks represent 
composite UCMs that split a path into parts (sub-paths) that proceed concurrently ([al] and [a2] in the 
figure). Or-joins represent composite UCMs that can be concatenated in only one path (represented by 
[a3] joining [al], [a5] joining [a2], and [a7] joining [a6]). There is no level of concurrency associated with 
OR-joins. 

Figure 5 depicts the second level of the requirements model when mobility management procedures 
are decomposed into small units represented by Auth and Update stubs in the Location Registration plug- 
in bound to the MM stub in the root map. Alternative paths (called OR-forks) represent composite UCMs 
that can be split into two different paths (no level of concurrency is associated with them). For instance, a 
responsibility point (cross labeled cR in the figure) is activated along the |b2] path to decide whether the 
mobile station is registered or not at the current location area. The alternatives sub-paths (labeled [b3] and 
[b4]) are generated after this decision. Auth stub has two outgoing paths labeled [bl] and [b2] that 
correspond to end points of the authentication plug-in (respectively, unsuccessful and successful 
outcomes). The Update stub groups all the functions related to updating user information. 


Legend : 

S’ : Start 

Auth : Authentication 
Update: Location Updating 
cR : check Registration 
El’ : endUnsucAuth 
E2’: endUpdate 

[b1],[b2]: [auth. Denied], [Auth. Success] 
[b3],[b4]: [not Registered], [Registered] 



Figure 5 (a) Location Registration PI ug-in for MM Stub 
The main advantage of applying unbound UCMs when comparing with information descriptions is the 
visual representation of the overall system behavior since the early development stages. Under such 
circumstances, the system description becomes more readable and design decisions regarding to the 
mapping of the reference architecture, exchanged messages and data types are easier to handle at the later 
stages. 

4.2. Analysis Model: Bound UCMs 

At the analysis stage, the previous stubs are detailed with responsibility points along the paths that 
identify actions, events, or operations on data items. Figure 6(a) details the Auth stub. First, the mobile 
station processes the user authentication and sends the authentication result to the network (si 
responsibility). Then, the aAA responsibility performs the same authentication operation at the network 
side. The cAR responsibility generates the successful or unsuccessful outcomes (respectively, E2” or 
El” end points). In case of denied authentication, the mobile user is notified (nAD responsibility). 
Otherwise, the network is notified (nN responsibility). 

Figure 6(b) shows what happens inside the Update stub. For example, cL generates different 
outcomes according to whether the mobile user is roaming or not. uP and uTP responsibilities are 
operations on database items. Sub-paths labeled [cl] and [c2] are concatenated after the network is 
notified (nN responsibility) about the successful operation. 




Legend : 

S Auth; S updt ■ Start 

si: send Authentication Information 

aAA: apply Authentication Algorithm 

cAR : check Authentication Result 

nAD: notify Access Denied 

[cl] : [successful Authentication] 

[c2] : [unsuccessful Authentication] 

El’ Autti* endUnsucAuth 

E2”au»,: endSucAuth 

cL: check Location 

uP : update Home User Profile 

uTP : update Visitor User Profile 

nN : notify Network 

[dl] : [visiting location area] 

[d2] : [home location area] 

E2”upd t : endUpdate 


(a) Authentication (b) Update Information 



Figure 6 (a) Authentication and (b) Update Information Plug-ins 

Besides describing detailed scenarios as causal paths with new plug-ins bound to the stubs at this stage, 
organizational structures of system components (represented by rectangular boxes as shown in Figure 7) 
are added. For instance, WmATM components involved in the authentication and update information 
functions, Mobile Stations , WmATM switch and Home and Visitor Databases are mapped to the unbound 
UCMs described at the requirements model. 


(a) Authentication 



(b) Update Information 


Visitor 

Database 



Figure 7 Bound UCMs: Authentication and Update Information Plug-ins 
Related and Future Work. With the increasing popularity of the Unified Modeling Language (UML) for 
modeling systems using object-oriented concepts, UCMs are currently being investigated as another UML 
artifact to help the system development process. According to [2], UCMs can help to bridge the gap 
between the use case model and the analysis and design models represented by behavioral diagrams 
(sequence, state charts, and activity diagrams) in the UML. We intend to apply UCMs as an alternative 
for the early stages of the function-oriented development process combined with a strong formal method 
such as LoTOS and MSCs. In short, our approach brings more powerful tools to tackle the verification 
problem (how can a designer solve a given problem systematically so that requirements are realized) in 
large systems. Object-oriented analysis and design that are the subject of UML is one step further and it is 
considered as future work. 

Besides the comparison with UML, as a graphical notation, UCMs resembles petri nets at a first 
sight, but many differences can be quickly perceived. For instance, use case maps are based on causality 
events while petri nets are based on states or events. Also, semantics are not defined for UCMs, they are 
often applied to the early stages of the development process to give a global picture of the system, they 
are light-weight, easy to leam, and the underlying architecture can be also expressed using this notation. 
On the other hand, petri nets have strict semantics, are rich in analysis methods, have automated tools that 
are rigorous and soundness. Besides this, the latter is more appropriate to the design stage and more 




feasible to be compared to formal languages like LoTOS and Specification and Description Language 
(SDL). A mapping of UCMs to petri nets can be investigated as future work. 

5. WMATM SPECIFICATION AND VALIDATION WITH LOTOS 

At the design stage, a formal model is generated based on the bound UCMs described earlier. LoTOS has 
many advantages to specify and validate complex and large systems. For example, different levels of 
abstraction can be used to describe functional behavior at different development cycles, not to mention 
the LoTOS ability of process instantiation and parallel composition to specify the system reference 
architecture with the sequence of responsibilities defined previously at the requirements and analysis 
models. LoTOS tools like the LOLA environment are available to automatically support validation and 
verification methods. These methods allow the detection of design errors, inconsistencies and 
incompleteness at the time the LoTOS specification is being developed. 

Since the behavior and structure models are iterative and incrementally generated at the requirements 
and analysis stages, the LoTOS specification becomes easier to develop. In addition, the gap between 
stages is also reduced by moving from bound UCMs (such as Figure 7) to LoTOS processes and gates 
shown in Figure 8. Even though the processes are derived from the UCM system components, design 
decisions related to how they communicate through gates are not always straightforward and depend on 
real interfaces and synchronization needs. 



Figure 8 Graphical Representation of the LoTOS Specification Architecture 


At the highest level of abstraction, the specification is composed of Wireless mobile ATM Network, ATM 
Transmission Link (depicted in gray in the figure to differentiate from the processes described also as 
UCM system components at the previous stages) and ATM Network processes. Wireless mobile ATM 
Network includes mobile stations (originating and terminating sides), WmATM switches (same process for 
previous and current WmATM switches ), home databases (referred to Home Location Register - HLR in 
the specification), and visitor databases (referred to Visitor Location Register - VLR) sub-processes. 
These processes are synchronized through the following gates: ms_wsh, vlr_wsh, wshlink, and 
hlr_link. ATM network process contains fixed stations and ATM switches connected through gate fs_sh 
(not shown in the figure for lack of space). ATM transmission link process are added to this stage in order 
to overcome a LoTOS limitation and provide the communication among WmATM switch processes 
(through gate wsh_link) and among ATM switches processes (through gate shlink). Gates e_ms and 
e_fs provide the interaction of mobile and fixed stations with the environment (for simulation purpose). 

Figure 9 depicts how theses processes synchronize through the gates (III represents the interleaving 
operator and l[gate list]l the selective parallel operator). The use of these LoTOS operators allows process 
synchronization and the ability to simulate and test the whole system behavior. Data types are designed to 
guarantee information exchange among processes. In particular, each MobileStation is identified by its 
identification number ( user A , user B. and User C in the figure), electronic serial number, random 
variable, secret key (these identifiers are represented by info_A, info B and info_C ), home database 
(hlr_l and hlr_2) and current zone (zone_l and zone_2). Each WmATM switch has its identification 
(zone_l and zone_2 in the figure). HLR and VLR processes keep an identity and information about mobile 
stations in a set of database record (called HLRRecSet and VLRRecSet, respectively). 


behavior 

hide ms_to_wsh, vlr_to_wsh, hlr_to_link, wsh_to_link, fs_to_sh, sh_to_link in 

(( WirelessMobileATMNetwork [e_to_ms, ms_to_wsh, wsh_to_link, vlr_to_wsh, 
hlr_to_link] | | | ATMNetwork [e_to_fs, fs_to_sh, sh_to_link] ) 

| [wsh_to_link, sh_to_link, hlr_to_link] | 

ATMTransmissionLink [wsh_to_link, sh_to_link, hlr_to_link] ) 

where 

process WirelessMobileATMNetwork [e_to_ms, ms_to_wsh, wsh_to_link, vlr_to_wsh, 
hlr_to_link] : exit := 

( (* users power on the mobile station *) 

( MobileStation [e_to_ms, ms_to_wsh] (user_A, info_A, zone_l, hlr 1, 0) 

| | | MobileStation [e_to_ms, ms_to_wsh] (user_B, info_B, zone_l, hlr 1, 0) 

| | | MobileStation [e_to_ms, ms_to_wsh] (user_C, info_C, zone_2, hlr_2, 0) ) 

| [ms_to_wsh] | 

( (WmATMSwitch [ms_to_wsh, wsh_to_link, vlr_to_wsh] (zone_l) 

| [vlr_to_wsh] | VLR [vlr_to_wsh] (vlr_l, InitialVLRSetl) ) 

| | | (WmATMSwitch [ms_to_wsh, wsh_to_link, vlr_to_wsh] (zone_2) 

| [vlr_to_wsh] | VLR [vlr_to_wsh] (vlr_2, InitialVLRSet2 ) ) ) 

| [hlr_to_link] | (HLR [hlr_to_link] (hlr_l, InitialHLRSetl ) 

| | | HLR [hlr_to_link] (hlr_2, InitialHLRSet2 ) ) ) ... 

Figure 9 Highest Level of Abstraction of the LoTOS Specification 
The behavior of each process is first generated based on the sequence of UCM responsibilities (for 
instance, from Figure 4, Figure 5, and Figure 7 to Figure 10). After that, both informal descriptions and 
information flows presented in [5] and [6] are considered to add more details to the specification such as 
data types and specific messages. During this stage, duplicate behavior and incomplete scenarios related 
to the signaling protocols are detected and corrected using the simulation and testing Lola tools. For 
example, in our specification the same procedure is used for connection establishment between two 
mobile users as well as between mobile and fixed users minimizing duplicated behaviors. Also, more 
unsuccessful scenarios are described, such as power off, handoff failure and disconnection (represented 
by the [> disable operator). These scenarios happen at any time after the user powers on or the connection 
establishment. Figure 10 depicts part of the behavior of the MobileStation process when a mobile user 
powers on and authentication and update information plug-ins are triggered as shown in Figure 7. 



Figure 10 Partial Behavior of the MobileStation Process 


LOLA is a transfomiational and state exploration tool that supports execution and testing of LoTOS 
specification. To do this, LOLA provides a set of tools that help designers to analyze the behavior of a 
system before the implementation stage. The following tools are applied to our specification: simulation 
or debugging that simulates the behavior step by step and evaluates data value expressions; and testing 
that calculates the response of a system specification to a test according to testing equivalence. The one 





expansion transformation tool is also used to generate a file with a trace (one possible scenario). Next 
sub-section presents MSC scenarios that are automatically generated from LoTOS validation traces 
contained in these files. 

6. SCENARIOS WITH MESSAGE SEQUENCE CHARTS 

MSC is the favorite notation to describe scenarios of current systems and many basic sequence diagrams 
are used at the early phases of the development of large systems, standards and to represent early behavior 
model in object-oriented approaches. Nevertheless, these diagrams are static and disjoint, only one 
sequence of events can be observed at once. Due to these characteristics, validation and verification 
techniques are not possible and in [4], we propose their use as a complement of formal methods such as 
LoTOS and SDL [16]. Recently, High-Level MSCs include control stmctures that can combine several 
MSCs representing more than one scenario, however, they are not considered in our work. By adding 
these scenarios to the proposed approach, we aim to represent the results of the LOLA validation 
activities. Successful and unsuccessful MSC scenarios can be more readable and attractive than LoTOS 
traces and they can be used for implemented to generate the protocols. 

The generation of MSCs is done automatically with the Lotos2MSC converter tool. This tool uses a 
configuration file that interprets the LoTOS traces and generates proper MSC scenarios. To make this 
possible, the converter uses conventions and additional configuration information to decode a LoTOS 
action and its elements (the sequence of values) to derive MSCs components, messages and parameters. 
The converter restricts LoTOS capability of full-duplex communication through gates (no direction is 
associated to the execution of LoTOS actions among processes) by demanding that gates represent 
directions and components. Since LoTOS generic concept of action defines messages and parameters 
implicitly in terms of abstract data types, as mentioned above, the tool can only recognize messages and 
parameters when they are described in the LoTOS action. A direct mapping of LoTOS to MSC concepts 
is not done due to LoTOS synchronization of many simultaneous actions in contrast to MSCs exchange of 
messages between components. This converter also allows filtering specific LoTOS actions that the 
designer wants to be displayed on the MSC graph using gate names as filtering criteria. More details 
about this converter can be found in [25], 

Figure 11 illustrates two disjoint scenarios that represent specific behaviors of the system in 
conformance not only with the LoTOS specification (Figure 10) but also the bound UCMs (Figure 7(a)). 
For sake of clarity, we represent WmATM switch process as current WrnATM switch. 



Figure 11 (a) Successful Authentication (b) Unsuccessful Authentication 


By comparing these MSCs with some of the protocols presented in the literature, decisions such as the 
authentication result initially being done at the MS side and also network side is clearer and guarantee 
security through the air interface (more complete design). Also, details about parameters make the 
implementation easier. 

Due the popularity of sequence diagrams, most tools for formal methods bring options in how to 
generate MSCs from the validation results. For instance, the SDL Development Tool set (SDT) and the 
SPIN tool support the process of going from the formal design to MSCs. Work on providing the 
requirements first in terms of sequence diagrams and then applying more formal verification techniques 
such as the ones supported by the SPIN model checker [15] to these diagrams is presented in [14]. This 
process is also a recent research interest for the SDL and LoTOS communities. We believe that these 




solutions as well as our approach are valuable and lead to a more effective and attractive way to design a 
system and present the validation and verification results to users and developers. 

7 . CONCLUSION 

Current development approaches for wireless mobile ATM (WmATM) networks describe all specific 
information related to the signaling protocols at once. However, a good approach should iterative and 
gradually add details during different development stages and life cycles, while checking for ambiguities, 
inconsistencies, and undesirable interactions. In this context, the main contribution of this work is to 
introduce the combination of different techniques at appropriate stages of the system development 
process. As a case study, mobility, communication and handoff procedures for WmATM networks are 
developed using the proposed approach. 

In short, at the requirements capture stage, unbound Use Case Maps (UCMs) are used as first 
scenarios by focusing on the causality relationship between responsibilities, without any concern about 
components. At die analysis stages, system components and more behavior details are added to these 
maps, generating bound UCMs. This notation provides a better human understanding of the system and it 
helps network designers to produce descriptions of the requirements more legible as well as facilitates the 
system development and maintenance. At the design stage, a formal specification is developed with 
UoTOS adding rigor to the approach and many possible behaviors are described concurrently with details 
such as data types, parameters and specific events. A set of LoTOS tools assures the completeness of the 
system and verifies correctness and consistency properties. MSCs scenarios are automatically generated 
from the results of the LoTOS validation in order to facilitate future protocol implementation. 

The proposed approach improves the existing current development process for wireless mobile ATM 
networks in different ways as follows: by achieving a better model, by helping human understanding and 
by reaching technical quality with the fomtal specification for future maintenance. Using our approach, 
inconsistencies of parameters and incompleteness of the informal description are detected and corrected. 
In addition, the UCM technique can reduce the gap between early and later stages. Our results also intend 
to show how the combination of informal and formal techniques at the appropriate development stages 
can really aid designers on generating good systems, ready to be reused and easy to maintain and add new 
features. 

The motivation for choosing WmATM networks resides in their under development status and also 
the amount of information available about the signaling protocol alternatives. This makes feasible to 
produce the design prototype with the proposed approach. Our approach can also be applied to other 
wireless mobile communication systems. The Ottawa University LoTOS Group has successfully applied 
LoTOS to the specification and validation of mobile network standards, such as Global System for 
Mobile Communication (GSM) [27], and UCMs to the description of Wireless Intelligent Network 
standards [26] as presented in [3], Currently, the combination of these techniques is being one of the main 
research topics of our group. 
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Abstract 

This paper describes two separate efforts that used the 
SPIN model checker to verify deep space autonomy flight 
software. The first effort occurred at the beginning of a 
spiral development process and found five concurrency 
errors early in file design cycle that the developers ac- 
knowledge would not have been found through testing. 
This effort required a substantial manual modeling effort 
involving both abstraction and translation from the pro- 
totype LISP code to the PROMELA language used by 
SPIN. This experience and others led to research to ad- 
dress the gap between formal method tools and the de- 
velopment cycle used by software developers. The Java 
PatliFinder tool which directly translates from Java to 
PROMELA was developed as part of this research, as well 
as automatic abstraction tools. In 1999 the flight software 
flew on a space mission, and a deadlock occurred in a 
sibling subsystem to the one which was the focus of the 
first verification effort. A second quick-response “clean- 
room” verification effort found the concurrency error in a 
short amount of time. The error was isomorphic to one 
of the concurrency errors found during the first verifica- 
tion effort. The paper demonstrates that formal methods 
tools can find concurrency errors that indeed lead to loss 
of spacecraft functions, even for the complex software 
required for autonomy. Second, it describes progress in 
automatic translation and abstraction that eventually will 
enable formal methods tools to be inserted directly into 
the aerospace software development cycle. 


1 Introduction 

Complex concurrent software is difficult to debug and 
even more difficult to test with adequate coverage. With 
file increasing power of flight-qualified microprocessors, 
NASA space enterprises are experimenting with a new 
generation of non-deterministic flight software that pro- 
vides enhanced mission capabilities. A prime example is 
the Remote Agent (RA) autonomous spacecraft controller 
developed at NASA. In May 1999, the RA was success- 
fully demonstrated in flight on Deep Space 1 (DS-l), the 
first flight of NASA’s experimental New Millennium pro- 
gram. The RA is a complex, concurrent software system 
employing several automated reasoning engines using ar- 
tificial intelligence technology. The verification of such 
complex software is critical to its acceptance by science 
mission managers. 

This paper describes formal methods verification ef- 
forts for one of the three subsystems of the RA - specifi- 
cally, file RA Executive, which provides operating-system 
level capabilities for goal-directed software. Two differ- 
ent verification activities were conducted, before and af- 
ter flight, using different technologies and in very differ- 
ent contexts. As such, this paper provides two succes- 
sive snapshots of progress towards making formal meth- 
ods verification cost-effective. 

In 1997, while the RA was still in the development 
stage, we modeled and verified a subset of the core ser- 
vices of the RA Executive using the SPIN [10] model 
checker. That verification unveiled several concurrency 



bugs that were acknowledged by RA Executive develop- 
ers [7], 

As a result of this effort, it was decided to develop 
model checking technology for a mam stream program- 
ming language in order to reduce the amount of time spent 
on modeling the behavior of programs in SPIN. The result 
was a translator, called Java PathFinder, from Java to the 
modeling language PROMELA of SPIN. In addition, a 
tool was developed for abstracting Java programs to re- 
duce their state space, making model checking tractable. 

Then, during the actual RA experiment in 1999, a dead- 
lock occurred within less than 24 hours of operation. Al- 
though the problem was promptly identified and circum- 
vented by the DS-1 team, we took the challenge of try- 
ing to diagnose the error in a fast-response “clean room’’ 
experiment 1 . After isolating a suspicious part of the pro- 
gram by visual inspection, we modeled it hi Java, and then 
used Java PathFinder to exhibit a concurrency error that 
indeed turned out to be the one that had occurred in flight. 

One key observation of these two successive experi- 
ments is that the error that caused the deadlock is ex- 
actly isomorphic to one of those found using SPIN two 
years before in another part of the code. It is a concur- 
rency error, whose activation depends on a priori unlikely 
scheduling conditions between concurrent tasks. In fact, 
this error did not appear in over 300 hours of system-level 
testing on JPL’s flight system testbed. The conditions un- 
der which it occurred in flight were not anticipated during 
testing. A principal benefit of model checking technolo- 
gies is to be able to exhaustively cover scheduling alter- 
natives. This paper gives a compelling illustration of how 
model checking found an error that was a priori unlikely 
but did actually occur. It also discusses gaps between pre- 
vious formal method tools and requirements for making 
them easily accessible to system developers for ‘in the 
loop’ verification. Technological advances towards nar- 
rowing this gap are described in the context of the RA 
verification. 

Section 2 describes the RA experiment. Section 3 de- 
scribes the verification effort before flight, while Section 
4 describes the verification effort after flight. The sec- 
tion also presents Java PathFinder. Section 5 describes 
the Java abstraction tool, and finally, Section 6 contains a 
conclusion. 


1 By “clean room” we are referring to the fact that, while the verifica- 
don was post -facto, the team had no interaction with the actual debug- 
ging team. 


2 The Remote Agent Experiment 

To prepare for space exploration programs of the next 
decades within a reduced budget, NASA has set up the 
New Millennium program: a series of technology vali- 
dation flights whose objective is to accelerate the quali- 
fication for flight of new spacecraft technology. One of 
the objectives of the New Millennium program is to in- 
crease spacecraft autonomy, moving from the low-level 
control sequences currently in use towards mission-level 
planning and autonomous health monitoring and recov- 
ery. 

Deep Space 1 (DS-1), the first New Millennium Mis- 
sion, was launched from Cape Canaveral on October 24, 
1998 and ended its primary mission in September 1999 
(it is still operating and is on its way for a comet en- 
counter in 2001). During that mission, it successfully 
tested 12 cutting-edge technologies such as ion propul- 
sion, on-board optical navigation, and the Al-based Re- 
mote Agent, marking the first operational use of artificial 
intelligence during space flight. 

In its initial design, the RA Experiment (RAX) on DS- 
1 consisted of a short, limited 12-hour scenario designed 
to gain confidence in the RA, followed by a complete 
6-day scenario that was the full RA test. Later, the ex- 
periment had to be compressed into a single 2-day sce- 
nario, to accommodate external mission constraints. The 
original scenarios were designed to cover a formal list 
of validation objectives. To protect the main DS-1 mis- 
sion from possible misbehaviors of RA, the design in- 
cluded a “safety net” that allowed the RA experiment to 
be completely disabled with a single command, issued ei- 
ther from the ground or by on-board fault protection. 

The RA went through a thorough qualification process 
before being allowed to run orr DS-1. Though some for- 
mal verification tasks, such as the one reported here, were 
performed as feasibility studies, the formal qualification 
process relied on more conventional testing approaches. 
However, since the RA was a flight experiment, and not 
flight software, it was not subjected to the testing stan- 
dards of the latter. 

This section is a short summary of the flight qualifica- 
tion and experience of the RA [2, 13], 

2.1 Remote Agent 

The RA is an autonomous spacecraft controller developed 
by NASA Ames conjointly with the Jet Propulsion Labo- 
ratory (JPL) [12]. It comprises three components: 



• The Planner and Scheduler (PS) [11] generates flex- 
ible plans, specifying the basic activities that must 
take place. Given a mission goal, it produces se- 
quences of tasks for achieving this goal using avail- 
able system resources. 

• The Smart Executive (EXEC) [14] receives the plan 
from the Planner/Scheduler and then commands 
spacecraft systems to take the necessary actions to 
achieve and maintain the specified spacecraft states. 

• The Mode Identification and Recovery component 
(MIR), called Livingstone [16], monitors the state 
of the spacecraft, detects and diagnoses failures and 
suggests recovery actions to the Executive. 

The Executive subsystem is fire focal point of fire verifi- 
cation work discussed in this article. It combines features 
of multi-threaded operating systems with aspects of A I 
languages based on sub-goaling, such as Prolog. It is con- 
ceptually composed of three layers: a set of core sen-ices 
that implement a robust operating system for executing 
concurrent tasks, a set of engine modules including a plan 
runner, and a set of mission-specific task programs. The 
Executive schedules fire execution of concurrent tasks. It 
also monitors a set of properties associated with system 
resources, and takes recovery actions on property viola- 
tions. The Executive is written in a multi- threaded LISP, 
using a set of LISP macros called the Executive Sequenc- 
ing Language (ESL) developed at IPL. 

2.2 Testing the Remote Agent 

Because autonomous systems such as the RA need to re- 
spond robustly in a wide range of situations, verifying that 
they respond correctly in all situations would require a 
huge number of test cases. Furthermore, these tests ide- 
ally have to be run on high-fidelity testbeds that are highly 
oversubscribed, hard to configure, and, running at real 
time speeds, take hours or days for a single run. 

To address these problems, the RAX team followed a 
“baseline testing” approach, starting from nominal sce- 
narios and testing a number of nominal and off-nominal 
variations around these scenarios. A wide range of varia- 
tions were run on more available and faster low-fidelity 
testbeds, leading to the identification and resolution of 
100-200 bugs during 18 months. An automated test- 
ing tool was designed for this purpose. Some of the 


most likely off-nominal variants were run on medium- 
fidelity testbeds, while only nominal scenarios and cer- 
tain performance and timing related tests were performed 
on high-fidelity testbeds. The final stage was a pair of 
“dress rehearsal” operational readiness tests (ORTs), in- 
volving actual communication with die mission control 
center. The bulk of file problems identified during testing 
were found with the low-fidelity testbeds. The ORTs only 
identified minor shortcomings that were resolved prior to 
flight. 

2.3 Remote Agent in Flight 

On Monday, May 17th, 1999, 1 1 :04 am PDT, a telemetry 
packet confirmed that die RA had taken control of DS- 
1. The scenario went on smoothly, achieving 70% of die 
objectives, until Tuesday 7 :00 am, when it became appar- 
ent that a command had not been executed as expected 
by file RA. The RA Executive was blocked, although die 
rest of the RA and file spacecraft were otherwise healthy. 
The Executive’s low-level commands were used to gather 
a maximum of information, and then file experiment was 
interrupted. 

By late Tuesday afternoon, the RAX team had found 
file source of the problem in the Executive code. They 
designed a 6-hour scenario that was run on Friday morn- 
ing and went successfully through the remaining 30% of 
the objectives. A patch was also generated, but the DS-1 
mission decided not to uplink it, considering the insuffi- 
cient testing of the patch and the very low probability of 
file problem recurring. 

The blocking was due to a missing critical section 
that had lead to a race condition between two concurrent 
threads. Under some very precise and unlikely timing cir- 
cumstances, both threads could end up in a deadlock con- 
dition in which each one was waiting for an event that 
only the other one could provide, which is exactly what 
happened in flight. 

3 Formal Analysis Before Flight 

hi April-May 1997 we analyzed pail of the RA Executive 
using the SPIN model checker [7]. This effort lead to the 
discovery of five errors in the LISP code which are de- 
scribed below. As discussed in Section 4.3, one of these 
errors is isomorphic to the error that actually occurred 
during flight, causing a deadlock. First we give a short de- 
scription of SPIN and its modeling language PROMELA. 



Then we explain how a PROMELA model was extracted 
from the LISP code, and how properties were stated and 
verified in the model, leading to the discovery of the five 
errors. We conclude with a discussion of the methodology 
that has been followed. 

3.1 The SPIN Model Checker 

SPIN [10] is a tool for analyzing the correctness of fi- 
nite state concurrent systems with respect to formally 
stated properties. A concurrent system is modeled in 
file PROMELA modeling language, and properties to be 
verified are formalized as assertions hi the program or 
as formulae in file temporal logic LTL ( Linear Temporal 
Logic). SPIN provides a model checker, which automat- 
ically examines all program behaviors in order to decide 
whether the PROMELA program satisfies the stated prop- 
erties. In case a property is not satisfied, an error trace 
is generated, which illustrates the sequence of executed 
statements from file initial state to file state that violates 
file property. These error traces can then be executed in 
a simulator. The set of states reachable from the initial 
state must be finite hi case a property needs to be proven 
correct for the whole state space. 

A PROMELA program consists of a set of sequential 
processes that communicate via message passing through 
bounded buffered channels and via shared variables. Pro- 
cesses can be created dynamically. The behavior of an 
individual process is described using the statement lan- 
guage which provides many standard constructs such as 
variable assignments, channel communications, loops, 
conditionals, and sequential composition. Variables are 
typed, where a type can either be primitive, such as in- 
teger, or composite in the form of arrays and records. 
PROMELA provides inline procedures, which is a lim- 
ited notion of procedural abstraction that is implemented 
via macro expansion. 

Each process represents a finite automaton, and the 
global behavior of the system is then obtained by comput- 
ing on-the-fly an asynchronous interleaving product of all 
these automata, creating the global state space. To per- 
form model checking, SPIN translates (the negation of) 
any LTL formula into a Biichi automaton, and computes 
the synchronous product of tins and the global state space. 
The result is again a Biichi automaton. If the language of 
this automaton is empty it means that the formula is sat- 
isfied. SPIN searches the state space depth-first, creating 
the states on-the-fly. A partial-order reduction technique 


is used to prune the set of transitions to be explored. 

3.2 Creating a PROMELA Model 

The modeling activity focused on the core services of the 
plan execution module. The RA Executive core is de- 
signed to support execution of software-controlled tasks 
on board die spacecraft. A task often requires specific 
properties to hold during its execution. When a task is 
started, it first tries to achieve the properties on which it 
depends, after which it starts performing its main func- 
tion. Several tasks may try to achieve conflicting proper- 
ties; for example, one task may try to turn on a camera 
while another task tries to turn it off. To prevent such 
conflicts, a task has to lock in a lock table any property 
it wants to achieve. Once, a property is locked, it can be 
achieved by file task locking the property. 

Properties may, however, be unexpectedly broken 
while tasks depending on them are executing. A property 
is defined as broken when it is locked in die lock table by 
some task, has been achieved (an extra boolean field in 
file lock table), but for some reason fails to hold on board 
file spacecraft. For the purpose of detecting which prop- 
erties hold on board, a database is maintained of all prop- 
erties being true at any time. Hence, an inconsistency can 
be detected by relating the lock table with the database. 
Tasks depending on a broken property must be interrupted 
and informed about the anomaly. For this purpose, a dae- 
mon monitors the changes on board the spacecraft, and in 
particular the consistency between the lock table and file 
database. The daemon is normally asleep, but is awak- 
ened whenever there is a change in the lock table or the 
database, where upon it checks their consistency. 

The PROMELA model focuses on operations on file 
lock table. Hence, it is an abstraction of the LISP pro- 
gram, omitting details irrelevant for the lock table opera- 
tions. The LISP program is approximately 3000 lines of 
code while the PROMELA model is 500 lines of code. 
Furthermore, the model only deals with a limited number 
of tasks and properties in order to limit the search space 
the SPIN model checker has to explore. Most abstrac- 
tions were made in an informal manner without any for- 
mal proofs showing that bugs are maintained. Hence, in 
the abstraction phase we may have left out errors in the 
LISP code. However, all the errors we found in the model 
were also errors in the LISP code. 

To give an idea of the modeling, we show how file dae- 
mon was translated, since it was the daemon that con- 



(defun daemon () 

( loop 

(if (check- locks) 

(do-automatic-recovery) ) 

(unless 

( changed? 

(+ (event -count * database- event* ) 
(event-count * lock- event*) ) ) 

( wait - for- event s 

(list * database -event* 

* lock- event * ) ) ) ) ) 

Figure 1: Daemon in LISP 


tained the error pattern which also occurred during flight, 
and which was found using the model checker. The actual 
LISP code describing the behavior of the daemon is given 
in Figure 1. 

The daemon goes through a loop, where in each itera- 
tion it checks the lock table, comparing it to the database, 
and recovers any inconsistencies that may be detected (if 
the check-locks function returns true). After that, it 
goes to sleep by calling the wait-for-events func- 
tion, which as parameters takes a list of events to wait 
for. Whenever one of these events is signaled, i.e. the 
database or the lock table is modified, the daemon will 
wake up and continue. 

In order to catch events that occur while the daemon is 
executing, each event has an associated event counter that 
is increased whenever the event is signaled. The daemon 
only calls wait - f or - event s in case these counters have 
not changed, hence, there have been no new events since 
it was last restarted from a call of wait-for-events. 

The PROMELA model of this LISP code is presented 
in Figure 2. The if-construct decides whether the daemon 
should stop and wait for a new database event or lock 
event to occur (call of wait.for_events), or whether 
it should continue for another iteration. Another itera- 
tion is needed if a database event or a lock event has oc- 
curred since the daemon was restarted last time; that is, in 
case the event counter event_count differs from the sum 
of the event counters for the database and lock events. 
If there is a difference, it means that there has been an 
event since the last tune event_count was updated, and 
the daemon must perform another iteration before calling 
wait_f or.events, first updating event_count to hold 
the new event counter sum. 


proctype daemon (Taskld this) { 
byte event_count = 0; 
do 

: : check_locks_and_recover ; 
if 

:: (Ev [DATABASE_EVENT] .count + 

Ev [LOCK_EVENT] .count 
== event_count ) 

- > 

wait_f or_events (this, 

DATABASE_EVENT , LOCK_EVENT ) 

: : else - > 

event_count = 

Ev [DATABASE_EVENT] .count + 

Ev [LOCK_EVENT] .count 
fi 
od 

}<• 

Figure 2: Daemon in PROMELA 

3.3 Stating and Verifying Properties 

The model was analyzed with respect to the following 
two properties, here expressed informally. The release 
property reads: “A task releases all of its locks before it 
terminates”. The abort property reads: “If an inconsis- 
tency occurs between the database and an entry in the 
lock table, then all tasks that rely on the lock will be ter- 
minated, either by themselves or by the daemon in terms 
of an abort” . The release property was formulated by in- 
serting an assertion in the code at the end of each task. 
This assertion stated that all locks should be released at 
this point. The second property was stated as a linear tem- 
poral logic property of the form: 

[] (propertyJbroken -> otasks.inf ormed) 

This property says: whenever a property is broken, 

then eventually all tasks depending on this property will 
be informed about it (in fact terminated). The names 
property Joroken and tasks_inf ormed are macro 
names standing for predicates on the state space. 

The attempted verification of the two properties led to 
the direct discovery of five programming errors - one 
breaking the release property, three breaking the abort 
property, and one being a non-serious efficiency problem 
where code was executed twice instead of once. The first 
four of these errors are classical concurrency errors hi the 
sense that they arise due to processes interleaving in un- 
expected ways. 



The error we want to focus oil in this presentation is the 
one isomorphic to the RAX anomaly. The error caused 
the abort property to be violated. The error trace gener- 
ated by SPIN demonstrated the following situation. The 
daemon is prompted to perform a check of the lock table. 
It finds everything consistent and checks the event coun- 
ters to see whether there have been any new events while 
it has been running. This is not the case, and the daemon 
therefore decides to call wait-f or-events. However, 
at tlais point an inconsistency is introduced, and a signal 
is sent by the environment, causing the event counter for 
the database event to be increased. This is not detected 
by the daemon since it has already made the decision to 
wait, which it then does, and the inconsistency now is not 
discovered by the daemon. Our suggested solution at the 
time was to enclose the test and the wait within a critical 
section, which does not allow scheduling interrupts to oc- 
cur between the test and the wait. Furthermore, two other 
flawed code fragments violated the abort property. 

The release property was violated in the sense that 
locks did not always get released by a task. The error trace 
generated by SPIN demonstrated that during a task’s re- 
lease of a lock, but before its actual release, the task may 
get interrupted by the daemon if the property gets broken. 
This means that the task terminates without releasing the 
lock. The error is particularly nasty in the sense that all 
code, except the lock releasing itself, had been protected 
against this situation: in case of an interrupt the lock re- 
leasing would be executed. 

The model was verified exhaustively using SPIN’S 
partial order reduction algorithm and state compression. 
Typically between 3, 000 - 200, 000 states were explored 
in the different models, using between 2-7 Mb of mem- 
ory, and using between 0.5 - 20 seconds. 

3.4 Discussion of Methodology 

The verification effort has been regarded by all involved 
parties as a very successful application of model check- 
ing, and of SPIN in particular. According to the RA pro- 
gramming team, the effort has had a major impact, lo- 
cating errors that would probably not have been located 
otherwise, and identifying a major design flaw. 

The modeling effort, i.e. obtaining a PROMELA 
model from the LISP program, took about 12 man weeks 
during 6 calendar weeks, while the verification effort took 
about one week. The modeling effort consisted concep- 
tually of an abstraction activity combined with a trans- 


lation activity. Abstraction was needed to cut down the 
program to one with a reasonably small finite state space, 
making model checking tractable. Translation, from LISP 
to PROMELA, was needed to obtain a PROMELA model 
that the SPIN model checker could analyze. 

The abstraction was done without any knowledge about 
the properties to be verified, since these were stated later. 
The abstraction maintained important operations on the 
lock table and ignored most other details of the orig- 
inal LISP program, hence, a kind of program slicing. 
No formal attempt was made to show that the abstrac- 
tions preserved errors. It is interesting that such an ad 
hoc approach still was extremely effective. The transla- 
tion phase was non-trivial and time consuming due to the 
relative expressive power of LISP when compared with 
PROMELA. 

Based on these observations, two research efforts were 
initiated that should make application of model checking 
within the software development cycle less resource de- 
manding. In one effort a translator from the Java pro- 
gramming language to PROMELA has been developed; 
see Section 4.2. In another effort, an abstraction tool 
has been developed, which can perform so-called predi- 
cate abstractions on Java programs; see Section 5. Both 
tools have been applied in the verification of the RA as 
described in the following. 

4 Formal Analysis After Flight 

Shortly after the anomaly occurred during the Remote 
Agent Experiment, on Tuesday May 18, the ASE team 
at NASA Ames heard that something had broken down 
in the RA while it was in control of the spacecraft and 
offered their help to the RAX team. On Lriday morning, 
after a few email exchanges, the RAX team provided ac- 
cess to the source code of the Executive, without identi- 
fying where the error was, and offered the ASE group the 
challenge of seeing “how long it would take for formal 
methods to come up with it”. 

On Friday afternoon, we decided to tun a “clean room” 
experiment to determine whether or not the technology 
currently used and under development in the group could 
have discovered the bug before it actually happened. At 
that time, we knew that debugging information collected 
from the spacecraft had enabled the DS-1 team to identify 
the bug and continue the experiment, and that the failure 
had something to do with a “handshaking" communica- 
tion between a Planner process and an Executive process. 



Other than these messages we had no further information, 
and no one in the ASE group had any contact with RAX 
personnel dining that week. 

This section first describes how the experiment was 
conducted. Then the Java PathFinder translator that was 
used to model check the flawed code is described. This 
is followed by a description of the error and how it was 
found using Java PathFinder. We conclude with a discus- 
sion of file methodology that has been followed. 

4.1 The Clean Room Experiment 

To make this clean room experiment credible, we de- 
cided that we would need to complete this exercise over 
file weekend, prior to the return of the RAX team from 
file DS-1 mission control at JPL the following Monday. 
This was both to avoid undue influence by people fa- 
miliar with file details of the bug, and also to meet the 
“short-tuniaround” challenge, mimicking what would be 
required if we were actually called on to provide “on-line” 
assistance. 

The experiment was set up as follows. A front-end 
group would try to spot the error by human inspection, 
or at least identify problematic parts of the code. On the 
basis of that, it would extract a more or less self contained 
portion of the code containing the problematic code por- 
tions, of a tractable size for a model checker. This ex- 
tracted code would then be handed over to the back-end 
group without any hints as to what could be the error. The 
back-end group would then try to locate the error using 
model checking. The situation was comparable to some- 
one doing visual inspection of code, and finding suspect 
sections which he wanted to explore further. 

The front-end team began perusing the code on Fri- 
day afternoon, and extracted roughly 700 lines containing 
questionable code 2 . The full group met again on Satur- 
day afternoon, and the front-end team gave the back-end 
team the extracted code. In accordance with the design of 
the experiment, they did not tell where the suspected bug 
was, but they briefed the back-end team on the control and 
data structures of the extracted code. The back-end group 
spent most of the time understanding that code in order to 
model it, and on Sunday morning came out with a fairly 
abstract model of the suspicious code. That model was 
written hi Java and verified with the Java model checker 
Java PathFinder, as described below. It reported a dead- 

2 Though they were not sure that they had indeed captured the con- 
currency error. 


lock, which turned out to be the one that had happened in 
flight five days before. 

4.2 The JPF Translator 

Java PathFinder (JPF) [8, 6] is a translator from a non- 
trivial subset of Java to PROMELA. Given a Java pro- 
gram, JPF translates this into a PROMELA program, 
which then can be model checked using SPIN. Java is an 
object-oriented programming language with a built-in no- 
tion of threads. Objects are instantiated dynamically from 
classes, which can be defined using single class inheri- 
tance. Threads, which are special objects with an activity, 
can communicate by making calls to methods defined in 
shared objects. Such methods can be defined as synchro- 
nized, thereby turning these shared objects into monitors, 
allowing only one thread to operate in the object at a time. 

In tiie default mode, the SPIN model checker will find 
any deadlocks present in the Java program. Such dead- 
locks can occur when several threads compete for access 
to tiie monitors. Properties can also be formulated explic- 
itly by the user, either as assertions in the program, or as 
linear temporal logic formulae. That is, a Java program 
can be annotated with assertions written as calls to a spe- 
cial assert method which takes a boolean argument ex- 
pression over the variables in the Java program. Any such 
call is translated into a corresponding PROMELA asser- 
tion, which will then be checked during tiie state space 
exploration whenever reached. Finally, SPIN’S own lin- 
ear temporal logic can be used to formulate properties 
over the Java program’s static variables (a static variable 
in Java is defined within a class, but is only allocated once, 
and hence is shared between all objects of the class). 

A significant subset of Java is supported by JPF: dy- 
namic creation of objects with data and methods, static 
variables and static methods, class inheritance, threads 
and synchronization primitives for modeling monitors 
(synchronized statements, and the wait and notify 
methods), exceptions, thread interrupts, and most of tiie 
standard programming language constructs such as as- 
signment statements, conditional statements and loops. 

The translator is written in 6000 lines of LISP, and was 
developed over a period of 8 months. JPF has been ap- 
plied to a number of case studies, amongst them a 1500 
line game server [9], a NASA file transfer protocol for 
satellites, and a NASA data transmission protocol for tiie 
space shuttle ground control. 

A related attempt to provide model checking technol- 



ogy for Java is described by Demartini et. al. [5], which 
also translates Java programs into PROMELA. However, 
their approach does not handle exceptions or polymor- 
phism as does Java PathFinder. In another related ap- 
proach, Corbett [4] describes a theory of translating Java 
to a transition model, making use of static pointer analy- 
sis to aid virtual coarsening, which reduces the size of the 
model. 


4.3 The RAX Error 

The suspected and eventually confirmed error was a miss- 
ing critical section around a conditional wait on an event. 
The relevant piece of code (anonymized for confidential- 
ity purposes) is shown in Figure 3. 

(loop 

(when 

(*1*) (or (/= count (esl :: event- count eventl) ) 
(*2*) (warp- safe (wait- for- event eventl) ) ) 

(setf count (esl :: event -count eventl)) 

(*3*) ( signal- event event2) ) ) 

Figure 3: The RAX Error in LISP 

This is the body of one of the concurrent tasks and con- 
sists of a loop. The loop starts with a when statement 
whose condition is a sequential-or statement 3 that states: 
if the event counter has not been changed (*1 *), then 
wait (*2*), else proceed. This behavior is supposed to 
avoid waiting on the event queue if events were received 
while the process was active. However, if the event oc- 
curs between (*1*) and (*2*), it is missed and the pro- 
cess goes asleep. Because the other process that produces 
those events is itself activated by events created by this 
one in (* 3 *), both end up waiting for each other, a dead- 
lock situation. 

This follows a similar pattern to the code shown in Fig- 
ure 1 that had been identified as a source of error during 
the verification of the Executive in 1997, as described in 
Section 3.3. This similarity was spotted by members of 
both the front-end and back-end teams, and contributed 
greatly to narrowing down the verification effort to this 
particular potential problem. 


3 (or X Y) is evaluated like if X then true else Y. 


4.4 Demonstrating the Error with JPF 

The modeling focused on the code under suspicion for 
containing the error. The major two components to be 
modeled were events and tasks, as illustrated in Figure 4. 
The figure shows a Java class Event from which event 
objects can be instantiated. The class has a local counter 
variable and two synchronized methods, one for waiting 
on the event and one for signaling the event, releasing all 
threads having called wait.for.event. Note how the 
counter is incremented by signal .event in order to al- 
low the tasks to check whether new events have arrived. 
The increment is modulo 3 in order to reduce the state 
space to be searched by the model checker. This is an in- 
formal abstraction in the sense that it has not been proven 
to preserve errors. Section 5 explains how an alternative 
counter abstraction for this program can be made and au- 
tomatically proved correct. 

class Event) 
int count = 0 ; 

public synchronized void wait_f or_event ( ) { 
try{wait() ; jcatch { InterruptedException e){}; 

} 

public synchronized void signal_event ( ) { 
count = (count +1) % 3; 

notifyAll ( ) ; 

} 

} 

class FirstTask extends Thread{ 

Event eventl, event 2 ; 
int count = 0 ; 

public void run ( ) { 

count = eventl . count ; 
while (true) { 

if (count == eventl . count ) 
eventl . wait_f or_event ( ) ; 
count = eventl . count ; 
event2 . signal_event ( ) ; 

} 

} 

} 


Figure 4: The RAX Error hi Java 

Figure 4 also shows the definition of one of the tasks. 
This is an abstraction (in Java) of the LISP code pre- 
sented in Figure 3. The task’s activity is defined in the 
run method of the class FirstTask, which itself ex- 



tends the Thread class, a built-in Java class that sup- 
ports thread primitives. The body of the run method 
contains an infinite loop, where in each iteration a con- 
ditional call of wait_f or_event is executed. The con- 
dition is that no new events have arrived, hence the event 
counter is unchanged. After having applied JPF, the SPIN 
model checker revealed the deadlock situation described 
in Section 4.3. In the Java context a new event arrived af- 
terthetest (count == event 1 . count ), but before the 
call event 1 . wait_f or_event ( ) . 

4.5 Discussion of Methodology 

The formal analysis of the Executive after the occurrence 
of file anomaly was preceded by a code inspection, which 
identified the possible source of the error. Some of us 
spotted the potential error situation because it resembled 
the similar error we had found using SPIN in 1997, as de- 
scribed in Section 3.3. Due to the focus on the particular 
code fragment, it was relatively easy to perform the ab- 
straction needed to extract a Java program with a small 
finite state space. This took about two hours. However, 
the suspicion was only a suspicion, and a demonstration 
that the code was flawed was provided using JPF. This 
showed the usefulness of using a model checker to an- 
swer focused queries. 

Since the original source code was in LISP, we still 
had to translate it by hand in Java, which goes against 
JPF’s intended puipose. To avoid that, one would need 
an abstraction tool and a translator for LISP. Since LISP’s 
future within NASA is questionable we have focused on 
providing these technologies for Java. Java is a very con- 
venient modeling language, providing most of the high 
level features of the powerful Common LISP Object Sys- 
tem (CLOS), such as dynamically created objects with 
methods and data. The major experience with all ex- 
periments done with JPF are obviously that a non-trivial 
amount of abstraction is needed in order to reduce the size 
of a program’s state space. This problem is addressed in 
Section 5. 

5 An Abstraction Tool for Java 

As a part of the JPF project, we have been developing 
an automated abstraction tool which converts a Java pro- 
gram to an abstract program with respect to user-specified 
abstraction criteria. The user can specify abstractions by 
removing variables in the concrete program and/or adding 


new variables (currently the tool supports adding boolean 
types only ) to the abstract program. Given a Java pro- 
gram and such abstraction criteria, the tool generates an 
abstract Java program in terms of the new abstract vari- 
ables and unremoved concrete variables. To compute the 
conversion automatically, we use a decision procedure, 
SVC (Stanford Validity Checker), which checks the va- 
lidity of logical expressions [1], 

The abstraction tool is designed to deal with object- 
oriented programs. The user can specify abstraction cri- 
teria for each class by removing field variables hi the class 
and/or adding new abstract variables to the class. There- 
fore, it can be used to abstract subcomponents in a pro- 
gram when file whole program is too complicated to ap- 
ply abstraction globally, hi addition, the user can specify 
new abstract variables which depend on variables from 
two different classes (inter-class abstraction). 

There has been similar work by others [3, 15], all of 
which require use of only global variables to describe 
a system in simple languages similar to guarded com- 
mands. However, our tool targets a real programming lan- 
guage Java and is able to deal with many problems caused 
by its object-orientation. 

5.1 Application of the Tool to the RA 

As we do not have enough space in this paper for a de- 
tailed explanation of the abstraction algoritlnn, let us il- 
lustrate the abstraction performed by the abstraction tool 
on a pail of the RA Java code shown in Figure 4. As 
stated before, state explosion occurs because of the un- 
bounded increase of the count variable in the Event class 
(in the original LISP code) and the assignment of the 
count variable in the FirstTask class (as well as in 
file SecondTask class which is not shown). Therefore, 
we use abstraction to remove those count variables by 
specifying Abstract . remove ( count ) in the classes of 
Event and FirstTask. hi place of these variables, we 
add new abstraction predicates which appear in file pro- 
gram with the count variables. For instance, we put 
Abstract . addBoolean ( "FcntEqEcnt " , 
count==eventl . count) in the definition of the 
FirstTask class to specify an abstraction predicate: 
FirstTask . count is equal to Event. count (For im- 
plementation convenience, object names are used to re- 
fer to class types.). We also used more filter-class ab- 
stractions such as FcntGeEcnt (FirstTask . count is 
greater than or equal to Event . count), ScntEqEcnt 



(SecondTask . count is equal to Event . count), etc. 

This is an example of an inter-class abstraction. 
Dealing with such inter-class abstractions is more in- 
volved than dealing with the abstractions inside one 
class. For each inter-class abstraction, the tool gener- 
ates an additional class definition in the abstract pro- 
gram, winch contains new boolean variables correspond- 
ing to the specified predicate. The boolean variables 
in the new class are defined as a two-dimensional ar- 
ray where each index refers to an object in either of 
the two classes. In Figure 5, the new abstract variable 
FcntEqEcnt .pred [Fobj ] [Eobj] corresponds to the 
user-defined predicate FcntEqEcnt for an object Fobj 
of FirstTask class and an object Eobj of Event class, 
i.e., Fobj . count = Eobj . count. 

Given the abstraction criteria, we now need to compute 
file value of the abstract variables in the abstract program 
so that they are consistent with the values of concrete vari- 
ables in the program. Figure 5 shows how the abstraction 
tool converts the assignment statement, count = count 
+ 1 (without the modulo operation) in Figure 4. Fust, 
the concrete assignment statement is omitted in the ab- 
stract program because the variable to be assigned has 
been removed. Instead, the tool checks which of the new 
abstract variables are possibly affected by this assign- 
ment and generates corresponding assignments to those 
abstract variables. For the example statement, a set of 
boolean variables that refers to ‘this’ Event object will 
be affected: FcntEqEcnt . pred [i] [this] in Figure 5 
(Actually, we use functions that return the corresponding 
index of a given object). To update those abstract vari- 
ables, a for-statement is used. For each of the abstract 
variables, the pre-images that leads the abstract variable 
to be true (or false) by the assignment are computed. 
Then the pre-images are mapped into the abstract domain 
by checking validity of the corresponding logical expres- 
sions. Finally, the results are used as a guard condition 
to set the abstract variables to true (or false). In the ex- 
ample, the variable FcntEqEcnt .pred [i] [this] will 
be set to false if it was true (or if some condition with 
another abstract variable holds). Otherwise, the variable 
is set to a non-deterministic boolean value. Because the 
concrete assignment statement is regarded as atomic, a set 
of these abstract assignments are declared as atomic for 
the IPF model checker. The additional statements for up- 
dating other abstract variables such as FcntGeEcnt are 
not shown in the figure. 


Verify .beginAtomic () ; 

/ / count = count + 1 ; 

for(int i = 0; i < FcntEqEcnt . numFirstTask; ++i) { 
if (FcntEqEcnt .pred [i] [FcntEqEcnt . getEvent (this) ] 

| FcntGeEcnt .pred [i] [FcntGeEcnt . getEvent (this) ] ) 
FcntEqEcnt .pred [i] [FcntEqEcnt .getEvent (this) ] = 
false ; 

else FcntEqEcnt .pred [i] [FcntEqEcnt . getEvent (this) ] 

= Verify . randomBool () 

} 

// similar code for updating other inter-class 
// abstract variables such as FcntGeEcnt, etc. 

Verify . endAtomic () ; 

Figure 5 : Output of the abstraction tool for the assignment 
statement 

5.2 Discussion of Methodology 

Using the tool, we have been able to obtain an abstract 
Java program of the RA code automatically. In the exam- 
ple, the unbounded integer variables are replaced by a set 
of boolean variables, hence the abstract program is free 
from the state explosion. Moreover, use of the tool helps 
to avoid error-prone abstractions based on human reason- 
ing. The tool generates a sound approximation of the 
concrete program using an automated validity checker, al- 
though it is not necessarily the most accurate one. 

However, the user must give reasonable abstraction cri- 
teria for the tool to generate a meaningful abstract pro- 
gram in order to check some desired properties. In case 
tlie abstraction criteria are not good enough, the result will 
be a too rough abstract program which can not preserve 
tlie properties to be checked. 

6 Conclusion 

This paper describes two major verification efforts carried 
out within the Automated Software Engineering Group 
at NASA Ames Research Center. The first effort con- 
sisted of analyzing part of the RA autonomous space craft 
software using the SPIN model checker. One of the er- 
rors found with SPIN, a missing critical section around a 
conditional wait statement, was in fact reintroduced in a 
different subsystem that was not verified in this first pre- 
flight effort. This error caused a real deadlock in tlie RA 
during flight in space. 

Such concurrency -related errors only happen as tlie re- 
sult of particular scheduling circumstances. Scheduling is 
totally uncontrolled when tests are run, and is highly sen- 



sitive to variations in the operating environment (e.g. op- 
erating system, other running tasks). This explains why 
the anomaly happened in flight, though it had not oc- 
curred even once in thousands of previous runs on the 
various ground testbeds. 

Developing the formal model of the program was, how- 
ever, a tune consuming task, requiring a manual trans- 
lation from the RA LISP code to the PROMELA lan- 
guage of the SPIN model checker. In addition, code de- 
tails had to be abstracted away in order to obtain a small 
enough finite state system that could be effectively model 
checked. The translation difficulty spawned the initiative 
to automate the translation from high level programming 
languages to modeling languages for formal verification, 
such as PROMELA. Java was chosen as the source lan- 
guage because of its modem programming language con- 
structs, such as support for object-oriented programming, 
and the standar dization across implementations of its con- 
currency constructs. An automatic translator from Java to 
PROMELA was designed and implemented, called Java 
PathFinder (JPF). With JPF one can model check smaller 
Java programs for assertion violations, deadlocks, and 
general linear temporal logic properties. The translator- 
covers a substantial subset of Java, illustrating the feasi- 
bility of the approach. 

In the second effort, JPF was used for modeling the 
RAX deadlock after it occurred. That is, after the front- 
end team isolated a reduced subset of the code that likely 
included the error, the back-end team developed a Java 
program which exposed the error. The translator trans- 
lated this into a PROMELA model, and the model check- 
ing of this model then immediately revealed the error. 
Java turned out to be an excellent choice as a modeling 
language, with a high level of abstraction, due to its object 
oriented features. In later work, a system that automates 
certain aspects of predicate abstraction was developed and 
successfully demonstrated on the same example. 

This experience gave a clear- demonstration that model 
checking can locate errors that are very hard to find with 
normal testing and can nevertheless compromise a sys- 
tem’s safety. It stands as one of the more successful ap- 
plications of formal methods to date. In its report of the 
RAX incident, the RAX team indeed acknowledges that 
it “provides a strong impetus for research on formal veri- 
fication of flight critical systems” [13], 

A posteriori, given the successful partial results, one 
can wonder why the first verification effort was not ex- 
tended to the rest of the Executive, which might have 


spotted the error before it occurred in flight. There are 
two reasons for that. First, the purpose of the effort was 
to evaluate the verification technology, not to validate the 
RA. The ASE team did not have the mission nor the re- 
sources needed for a full-scale modeling and verification 
effort. Second, the part of the code in which the error was 
found has been written after the end of the first verifica- 
tion experience. 

Regarding software verification, the work presented 
here demonstrates two main points. First of all, we be- 
lieve that it is worthwhile to do source code verification 
since code may contain serious errors that probably will 
not reveal themselves in a design. Hence, although design 
verification may have the economical benefit of catching 
errors early, code verification will always be needed to 
catch errors that have survived any good practice. Code 
will always by definition contain more details than the 
design - any such detail being a potential contributor to 
failure. 

Second, we believe that model checking source code is 
practical. The translation issue can be fully automated, 
as we have demonstrated. The remaining technical chal- 
lenge is scaling the technology to work with larger pro- 
grams - programs that could have very large state spaces 
unless suitably abstracted. Abstraction is of course a ma- 
jor obstacle, but our experience has been that this effort 
can be minimized given a set of supporting tools. 
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Abstract 

We describe a systematic approach to building tools 
for the automated analysis of specifications expressed 
in higher-order logic (hoi) independent of a conven- 
tional, interactive theorem proving environment. In 
contrast to tools such as HOL and PVS, we have taken 
“the hoi out of HOL” by building automated anal- 
ysis procedures from a toolkit for manipulating hoi 
specifications. Our approach eliminates the burden of 
skilled interaction required by a conventional theorem 
prover. Our lightweight approach allows a hoi specifi- 
cation to be used for diverse purposes, such as model 
checking, and the algorithmic generation of test cases. 
After five years of experience with this approach, we 
conclude that by decoupling hoi from its conventional 
environment, we retain the benefits of an expressive 
specification notation, and can generate many useful 
analysis results automatically. 

1 Introduction 

Formal methods have come a long way. Industrial 
standards such as IEC 61508, and DO-178B include 
explicit references to the use of formal methods as a 
means of increasing confidence in safety-related sys- 
tems. Formal methods add precision and checkability 
to various aspects of the system development process. 

A decade ago, there was a wide chasm between 
specialized automated methods such as model check- 
ing [6], specification- intensive methods such as the use 
of Z [33], and general proof-based reasoning found in 
tools such as HOL [16]. The input notations of the 
analysis tools matched the analysis capabilities of the 
tool. For example, the SMV [26] notation describes 
finite state machines, whereas the use of higher-order 
logic (hoi) 1 as the specification language of PVS cor- 
responds to the intended use of PVS [28] as an inter- 
active theorem prover. 

Progress is being made rapidly on bridging this 
chasm and uniting the capabilities of the various tools 

will use “hoi” or “Hoi” for higher-order logic by itself, 
and “HOL” to refer to the HOL theorem proving system. 


under one roof. For example, the SCR toolset in- 
cludes a consistency checker, a simulator, and links to 
a model checker, and a theorem prover [3, 20]. PVS 
has integrated a number of automated decision pro- 
cedures [27], Most of these examples are, however, 
either application-specific such as the SCR toolset, or 
start from a heavyweight theorem prover. 

We have been exploring a different point in the de- 
sign space of these combined systems. For the past 
five years, in an industry/university collaborative re- 
search project, we have used hoi as a specification no- 
tation and applied automated analysis techniques such 
as refutation-based approaches (i.e. , those that gen- 
erate counterexamples), and test generation to these 
specifications. We have taken “the hoi out of HOL” 
by building these automated procedures on top of just 
a parser and typechecker to eliminate the burden of 
skilled interaction required by a conventional theorem 
prover. 

The combination of hoi with automated analysis 
may seem crippled from the beginning: we do not have 
all the tools we might need to work with our specifica- 
tion. However, our experience shows that less power is 
often better. The expressiveness of higher-order logic 
allows us to embed more familiar notations within hoi. 
The difficulties for new users come when the only tool 
support available has a high learning curve, and they 
struggle to understand the feedback the tool provides 
them about their specification. We offer a solution 
that lessens the learning curve, delaying the need to 
use a theorem prover until the problem requires it and 
the user is ready for it. 

In Sections 2, and 3 we present our reasons for 
choosing to work with higher-order logic outside of 
a theorem proving environment. In Section 4, we de- 
scribe our toolkit, a collection of cooperating utilities 
that manipulate hoi expressions in “truth-preserving” 
ways, i.e., the result of every transformation could also 
have been produced by a formal derivation using infer- 
ence rules in HOL. In Section 5, we describe how the 
blocks are used in combination to construct analysis 
procedures such as symbolic model checking, and test 
generation. 



Unlike our related presentations of this project [8, 
9, 10, 14, 23], in this paper we focus on the capabili- 
ties of the tool and how it is engineered. This paper 
is intended to be a high-level view of the architecture 
of our analysis tool, illustrating how our toolkit facil- 
itates significant reuse of components for diverse ap- 
plications such as test generation and model checking. 
We have also created new analysis methods such as 
constraint-based simulation. Our focus on automated 
analysis compels us to provide the user with control 
of performance factors such as BDD [4] variable order. 
We have also created methods that allow us to main- 
tain the information necessary to produce readable, 
traceable results given in terms of the original spec- 
ification. References are provided to more technical 
descriptions of the components of our toolkit. 

By providing a lightweight interface between a 
general-purpose notation and automated analysis, we 
offer a middle ground between special-purpose anal- 
ysis tools and general-purpose theorem provers. Our 
goal is to bring the power of a range of automated 
analysis techniques to specifiers without sacrificing 
suitability and expressiveness of notation. 

2 Why higher-order logic? 

Initially, we chose higher-order logic as a specification 
notation independently of consideration for tool sup- 
port. Our notation S [23] is a syntactic variant of 
the object language of the HOL theorem proving sys- 
tem. S was also influenced by Z, in that it includes 
constructs for the declaration and definition of types 
and constants. It was developed to support the prac- 
tical application of formal methods in industrial scale 
projects. In this section, we explain our reasons for 
choosing to work with S. 

First, S is a general-purpose notation, it does not 
impose any particular style of specification. We have 
used it to capture a stimulus-response style of specifi- 
cation, as well as embedding other notations such as 
statecharts [17], and tables in S [2, 9]. By placing spe- 
cialized notations within a general-purpose environ- 
ment, we can take advantage of many general-purpose 
features such as parameterization, and re-usable aux- 
iliary definitions and infrastructure. In the specifica- 
tion of an aeronautical telecommunications network 
(ATN) written in our embedded statecharts style, we 
witnessed these benefits, which reduced the specifica- 
tion effort, and resulted in a more concise and read- 
able specification [2]. Also, we do not have to repeat 
the effort of building analysis tools for particular no- 
tations. Once a notation is embedded in S, many of 
our analysis tools can be applied. 

Second, S is a logic. We have found that uninter- 
preted constants in a logic play a key role in allowing 


us to match the level of abstraction found in require- 
ments specifications. Joyce has called uninterpreted 
constants, “a modern-day Occam’s razor” 2 and points 
out their value in filtering non-essential details and 
in improving the readability of the specification [25]. 
Uninterpreted constants can be used to represent ele- 
ments that have meaning to domain experts but whose 
definition is irrelevant for analysis of a requirements 
specification. For example, many air traffic control 
specifications depend on the “flight level” of an air- 
craft. The details of how the flight level is determined 
may be irrelevant for analysis of some aspects of the 
system. The calculation of the “flight level” can be 
captured by an uninterpreted constant. Analysis re- 
sults produced for a specification hold for any inter- 
pretation of the uninterpreted constants. While a fi- 
nal specification should be complete including defini- 
tions for all the constants, the use of uninterpreted 
constants during the process of writing a specification 
allows some results to be produced without having to 
specify all of the details. 

Furthermore, a logic contains quantifiers, which of- 
ten allow the expression of formal requirements to 
more closely correspond to their expression in natu- 
ral language. Quantified statements can be used to 
capture domain knowledge that describes the environ- 
ment of the specification. The ability to use a quanti- 
fier eliminates the need to spell out all instances where 
the environmental assumption is relevant. 

Finally, S is expressive; while we will never be able 
to prove automatically every property of our specifi- 
cations, our notation is unlikely to limit adding more 
automated analysis capabilities as they are developed. 

3 Why not use a theorem 
prover? 

In our approach, we have focused on automated anal- 
ysis of our specifications. There have been a vari- 
ety of successful efforts to combine theorem provers 
with automated decision procedures, such as PVS and 
Forte [1], Our experience with HOL- Voss [24] suggest 
that having the theorem prover control the link to the 
decision procedures is not the optimal approach for 
automated analysis. 

First, the infrastructure of the theorem prover is un- 
necessary for automated analysis and makes the ap- 
proach clumsy and intimidating to the novice speci- 
fier. These difficulties are a factor in industry’s resis- 
tance to formal methods. For example, we particularly 
wanted to avoid the need to learn a meta-language to 

“The Aristotelian principle, often attributed to William of 
Occam (1300-1349), that the simplest theory that fits the facts 
of a problem is the one that should be used. 



accomplish the specification task. Therefore, we made 
S the input language to our tool, and have very simple 
commands to invoke our analysis procedures. A sec- 
ond example is that rewriting by means of tactic appli- 
cation was used for expansion of definitions in HOL- 
Voss. This step was different for each specification an- 
alyzed. We have shown that an automatic technique, 
called symbolic functional evaluation, is sufficient for 
this task and requires no user intervention. 

Second, theorem provers are verification-based anal- 
ysis tools. The output of a theorem prover is the con- 
firmation of a conjecture. Often, more useful results 
of analysis are either evidence that refutes an inter- 
pretation of the requirements, or truth- preserving re- 
arrangements of the specification in order to distill 
atomic behaviour. Refutation-based techniques pro- 
duce a variety of results other than just theorems. 
For example, when analyzing a table for inconsis- 
tency, refutation-based techniques can clearly isolate 
the source of the inconsistency. Consequently, it is 
easier to interpret the result of a successful refutation 
attempt than a failed verification attempt. In using 
formal methods for an independent validation and ver- 
ification effort, Easterbrook and Callahan abandoned 
the use of PVS to carry out completeness and consis- 
tency checks because of the difficulty of determining 
the source of an inconsistency in a failed proof [15]. 

Third, the results should be expressed in terms of 
the original specification. In contrast to our approach, 
translating the specification for input to a specialized 
decision procedure often results in output in terms of 
the translated version. 

Fourth, most theorem provers do not currently pro- 
vide hooks to control analysis parameters such as BDD 
variable order. To work with large examples, control 
over these parameters is absolutely necessary. 

Theorem provers definitely have a role to play in 
the analysis of complex systems. We advocate an ap- 
proach that complements the use of theorem provers 
because we work with the same notation. Novice users 
and experts can work side-by-side. We have a tool 
that translates our S specifications to input for the 
HOL theorem prover [23]. 

4 The Toolkit 

Our toolkit consists of techniques that manipulate S 
expressions in truth- preserving ways. In this section, 
we describe the collection of techniques that are com- 
bined to build analysis procedures such as symbolic 
model checking. Figure 1 captures the architecture of 
our tool. In addition to the specification and com- 
mands, the input of semantic definitions allows the 
specifier to work with notations, such as statecharts, 
embedded in S. 



The representation of S expressions is encapsulated 
in an abstract datatype. The representation is cre- 
ated through the process of parsing and typechecking, 
common to all analysis procedures. Analysis proce- 
dures consist of a sequence of calls to the toolkit ele- 
ments, which manipulate S expressions to accomplish 
the analysis task. Each of the toolkit elements are in- 
dependent allowing them to be used systematically in 
combination to implement analysis procedures. Also 
the separation of concerns allows each toolkit element 
to evolve, and additional elements be added, without 
affecting other components of our tool. 

Some of the techniques, such as abstraction to 
propositional logic, can also be found in tools such 
as PVS. Others, such as symbolic functional evalua- 
tion (SFE) for expanding S expressions, we developed 
because we wanted to be independent of a theorem 
proving environment. In some cases, we rely on syn- 
tactic conventions for particular styles of specification. 
For example, we distinguish between the stimuli and 
responses for test generation based on vocabulary con- 
ventions. 

We also provide user access to performance tuning 
for some of these automated techniques. For example, 
while SFE is automatic, the user can control the depth 
of evaluation. For BDD-based analysis, we provide a 
way to input a variable order. 

4.1 Symbolic Functional Evaluation 

A specification consists of a collection of constant def- 
initions, and declarations of types and constants. If 
we are using an embedded notation, then a set of se- 
mantic definitions is added to this collection. Often, 






the first step in analysis is to expand all of these defi- 
nitions to determine the meaning of the specification. 

Symbolic functional evaluation [8] (SFE) is a tech- 
nique that we developed to “evaluate” or unfold S ex- 
pressions, i.e., carry out the logical transformations of 
expanding definitions, beta-reduction, and simplifica- 
tion of built-in constants in the presence of quantifiers 
and uninterpreted constants. It extends mechanisms 
from functional language evaluation to carry out lazy 
evaluation of S expressions. Unlike using quote sym- 
bols in a language such as Lisp, SFE gives the user 
control over the depth of evaluation. We illustrate 
this control with the following declarations and defi- 
nitions: 

z\ : num; 

fi, /a, h ■ num -> num; 

Z2 = /i(zi); 

Z3 = /a(^2); 

/4(a) = /3(a); 

The constants z\, /1, fa, and fa are uninterpreted. 
When we evaluate the expression f±{zz), we can in- 
struct SFE to evaluate to one of three levels of eval- 
uation. At the level of “complete” evaluation, it is 
expands all the definitions and returns the expres- 
sion fa(fa(fa(zi))). At the “point of distinction” level, 
SFE stops after it determines the tip of the expression 
is an uninterpreted function, and returns fa(z 3). One 
further level called “evaluated for rewriting” proved 
useful and evaluates the arguments of an uninter- 
preted function at the tip to the point of distinction. 
In this case, it would return fa{fa{z 2 ))- 

The choice of level of evaluation is linked with the 
choice of abstraction to be used for the automated 
analysis. For example, when abstracting an expres- 
sion to propositional logic (see Section 4.3), the point 
of distinction level is most appropriate because any 
details revealed by evaluation are lost in abstraction. 

Our implementation benefits from the use of struc- 
ture sharing in the representation of expressions, and 
caching of results. 

SFE can be used to carry out symbolic simulation 
of specifications of hardware circuits as has been done 
previously in theorem provers, e.g., [34, 35]. 

SFE provides functionality similar to that of PVS’s 
experimental ground evaluation, which translates a 
subset of PVS into Lisp for evaluation [32]. How- 
ever, SFE works for any expression in higher-order 
logic, including uninterpreted functions, and quanti- 
fiers. Our levels of evaluation provide a systematic 
means of controlling evaluation of these symbolic ex- 
pressions. A second difference is that we use SFE as 
the first step in the analysis process. In PVS, evalu- 
ation currently is stand-alone and does not affect the 
proof process. For our purposes, SFE is sufficiently 
fast for large specifications, however the PVS ground 


evaluation is no doubt faster using existing Lisp eval- 
uation and destructive updates where possible. 

4.2 Rewriting 

Once a specification has been sufficiently unfolded, 
several analyses require logical manipulation of the 
resulting S formula. A rewrite toolkit component is 
useful for performing this task. For example, the fol- 
lowing set of rewrite rules could be used to rewrite a 
specification so that negation (-1) is only applied to 
predicates: 

vx, y.x ^r = nivr 

VX, Y.-i(X A Y) = -iXV -Y 
VX, y.-.(X V Y) = -X A -Y 
VX.- 1 - 1 X = X 
VP.-.Vx.P(x) = 3 x.->P(x) 

VP.-i3x.P(x) = Vx.-P(x) 

Some analysis algorithms can be implemented as 
a series of rewriting operations. An example is the 
derivation of tests from an S specification using a series 
of sets of rewrite rules [10, 13]. Implementing the test 
generator using rewriting is a better way to preserve 
logical soundness than an implementation as a series 
of ad-hoc manipulations. 

Our lightweight rewrite system differs from some 
well-known rewrite systems, such as the one found in 
HOL. For performance reasons, our rewrite system co- 
operates with other means of simplification such as 
evaluating expressions with concrete values. The user 
of the rewrite system must ensure that each set of 
rewrite rules is confluent - otherwise, rewriting may 
not terminate. The user must also ensure that the 
rewrite rules are themselves sound. The checking of 
the rules need only be performed once as part of the 
development of an analysis procedure, and can be ac- 
complished using a theorem prover such as HOL or 
PVS. 

Rewrite rules are stated as universally quantified 
equalities, e.g., Vx.Ei(x) = E 2 (x), where x is a vec- 
tor of variables. For rules specifying rewrites involv- 
ing quantifiers and lambda abstraction: 1) variable 
capture is avoided using alpha conversion; and 2) if 
variable release occurs, the rewrite fails. 

The concept of variable release is the opposite of 
variable capture. During rewriting, if a variable is 
quantified in an expression matching the left-hand 
side of the rewrite rule and is not quantified in the 
corresponding instance of the right-hand side, vari- 
able release has occurred. For example, applying the 
rewrite rule VP, Q.fa/x.P V Q) = ((Vx.P) V Q) to 
Vx./(x) V y succeeds. However, applying the same 
rule to Vx./(x) Vj(x) fails because the x of g{x) is re- 
leased, i.e., x is no longer quantified because it was free 



in Q. The rewrite system also recognizes alpha equiv- 
alence, e.g., (A x.E(x)) = \a.E(a). By failing rewrites 
in which variable release occurs and recognizing alpha 
equivalence, we are able to describe as rewrite rules 
quantifier manipulation that requires conversions in a 
theorem prover. 

The rewrite system provides routines for applying 
a single rewrite to an expression, or to an expression 
and all its subexpressions. Sets of rules can also be ap- 
plied. The depth of a rewrite operation can be limited 
by providing a call-back function that examines the 
current subexpression and signals the rewrite system 
to continue with this subexpression or go no deeper. 

4.3 Abstraction to Propositional Logic 

By abstracting our specifications to propositional 
logic, we can produce conservative analysis results au- 
tomatically. As in Raj an [29], we decompose our S ex- 
pression based on the logical operators of conjunction, 
disjunction, and negation. The fragments are assigned 
unique Boolean variables with alpha-equivalent subex- 
pressions matched to the same variable. We maintain 
a table matching the fragments to their Boolean vari- 
ables to apply and reverse this process. 

We also deal with enumerated types so that they are 
represented by multiple, related Boolean variables as 
in Ever [22]. Sections 4.5 and 4.7 discuss elements of 
the toolkit that complement this abstraction process. 

We represent the expressions built from the Boolean 
variables using BDDs. A key to making this process 
efficient is to cache the match between S expressions 
and BDD expressions. Once a BDD expression is cre- 
ated, an analysis procedure can manipulate it with 
the usual BDD package operations such as negation, 
conjunction, and quantification. 

BDD variable order affects the size of the BDD rep- 
resentation of our S expression. For small examples, 
it is sufficient to create the BDD variable as needed 
in the abstraction process, but for larger examples, a 
better method was required. In PVS, it is possible 
to request that dynamic variable order be carried out 
within the BDD package doing propositional simpli- 
fication [31]. But, we found it critical to have direct 
support for providing the abstraction process with a 
BDD variable order to allow us to reuse a good order, 
as well as store and manipulate abstractions of ex- 
pressions. Furthermore, we wanted the variable order 
stated in terms of expressions of the specification, not 
in terms of the Boolean variables that are substituted 
for those expressions during abstraction. 

Therefore, we developed a way of supplying a 
variable ordering for BDDs as a list of S expres- 
sions. There are three types of substitutions: a single 
Boolean variable matched with a Boolean S expres- 


sion, partitions discussed in Section 4.5, and enumer- 
ated types. Each type of substitution is accompanied 
by a list of numbers giving the position in the order 
of the Boolean variables used to represent the S ex- 
pressions. We provide some utilities to help the user 
determine a good variable order by subcontracting the 
problem to existing verification tools such as the Voss 
Verification System [30]. Further details on our ap- 
proach can be found in Day [7]. 

Creating a Boolean abstraction of an S expression 
and then reversing the process, can be a useful method 
of simplifying expressions that include quantification 
over Boolean variables. The resulting expression is 
logically equivalent to the original. Our tool provides 
a command that evaluates an expression to the de- 
sired level of evaluation using SFE, creates a BDD 
representation of the expression, and then creates an 
S expression from the BDD. We used this process in 
constructing a large next state relation by construct- 
ing conjuncts representing concurrent states individu- 
ally first. 

4.4 Distinguishing Current and Next 
Values 

Specifications written in notations such as finite state 
machines describe a next state relation. Since S has 
no built-in notion of dynamic behaviour, a means is 
required to distinguish the value of a variable in the 
current state from its value in the next. Our toolkit 
implements three approaches to this problem based on 
syntactic conventions. 

The first approach is to make each variable a func- 
tion mapping system states to values for that variable, 
similar to the concept of variables as functions of time. 
The approach is well-suited for embedded state tran- 
sition notations, where the system state is implicit in 
the use of the variable. In this approach, we avoid 
the need to group the variables in a record structure 
explicitly as has been done in PVS [29], 

To support this approach to handling dynamic 
behaviour, an element of the toolkit separates the 
Boolean variables representing the current state val- 
ues from those for next state values after abstraction 
to propositional logic. In the semantics for embedded 
notations, we adopt the syntactic convention that the 
variable cf represents the current state, and cf the 
next state, thus a Boolean expression such as x(cf') 
refers to the value of the variable x in the next state. 
Expressions such as y(cf ) = ( y(cf ) + 1) that contain 
both cf and cf are considered as one Boolean variable 
belonging to the next state. 

A second approach is to adopt the convention of Z, 
where a prime (') is used to distinguish current state 
values from next state values. Thus, in the specifi- 



cation (z = g(x, 5)) =>■ (z' = g(x, 10)), z = g(x, 5) 
refers to the current state because it does not contain 
a primed variable. The presence of z' indicates that 
z' = g(x, 10) is a condition on the next state. 

A third approach uses the syntactic convention that 
a literal beginning with a lower case letter indicates a 
next state predicate. A command can specifically label 
a literal as referring to either state, overriding this con- 
vention. This mechanism is appropriate in situations 
where the vocabulary used to specify next state values 
is different from that of specifying current state values, 
e.g., some applications of system-level requirements- 
based testing [14]. 

In some cases, the convention used to distinguish 
values in time is intrinsically linked to the type of anal- 
ysis, and cannot be supported by an independent part 
of the toolkit. For example, the test generation pro- 
cess guides the rewrite system to distinguish stimuli 
from responses, placing expressions in certain forms. 

4.5 Interval Checking 

The process of abstracting to propositional logic is 
very conservative. It abstracts expressions such as 
x < 5, (5 < x A x < 10), and 10 < x to unrelated 
Boolean expressions, potentially causing the analysis 
results to return impossible cases. In this section, we 
consider options for avoiding this difficulty. One ap- 
proach is to rewrite predicates involving inequalities 
into a canonical form to find relationships between ex- 
pressions such as x < 5 and 5 > x. However, this fails 
to capture the relationship between x < 5 and 10 < x. 
A second alternative is to use an external tool to add 
constraints based on the numeric relationships [5], 

Instead of any of these choices, we chose a simple 
approach that was complementary to the process of 
abstracting to propositional logic, and that depended 
on the structure of the notation. Our approach treats 
related expressions that partition a numeric value as 
an enumerated type. Based on known structure of 
a particular notation, we can identify some related 
expressions without a global search of the complete 
specification. We encountered linear inequalities in 
tabular specifications where the cells of a row of a 
table partitioned the values of a numeric expression. 

We can identify the row structure within the speci- 
fication by searching for the Row keyword used in the 
embedding of the tabular notation. To exploit the 
structure we extended our tool with a registry mech- 
anism such that when certain keywords are encoun- 
tered by SFE, particular procedures are carried out. 
The Row keyword is associated with a simple “inter- 
val checking” algorithm that takes the list of expres- 
sions in a row and determines if they represent a non- 
overlapping partition. Our registry mechanism makes 


it possible to extend easily SFE with other structure- 
specific rules. 

In our current implementation, interval checking 
works for S expressions that contain numeric compar- 
ison operators and have a concrete value on at least 
one side of the operator. Interval checking also returns 
any ranges not used in the row entries. By treating the 
partition as an enumerated type, the related numeric 
expressions are encoded as related Boolean variables 
in the abstraction process. 

4.6 Readable Results 

A significant challenge in requirements analysis is re- 
turning results that are understandable and in the 
same terms as the specification despite the abstrac- 
tions used in analysis. One step towards this goal is 
maintaining the information to reverse the Boolean 
abstraction as described in Section 4.3. 

We are able to produce even better results by track- 
ing information through the expansion and logical ma- 
nipulation processes of SFE and rewriting. 

4.6.1 Unexpansion 

Through an enhancement of the representation of S 
expressions, we are able to return an expression in its 
unevaluated, and usually more compact, form. Tech- 
nically, lazy evaluation replaces a subexpression with 
its evaluated form, so the work of evaluation is done 
only once for all common subexpressions. We have 
modified our representation of expressions to include 
a pointer to the original, unevaluated version of the 
expression. 

At the expense of memory, we are able to keep both 
the evaluated and unevaluated forms of the expres- 
sions during SFE. Some analysis procedures choose 
to output the unevaluated form of the expression to 
present a more abstract representation of the output. 

4.6.2 Traceability 

Unexpansion is not sufficient when manipulations 
other than expansion are performed. For analyses that 
perform rewriting, it is often critical that the results 
be traceable to their source in the specification. 

For example, tests generated from a specification 
are logical consequences of it. If a test is produced 
that represents clearly unintended behaviour, then its 
source in the specification needs to be located before 
it can be corrected. In the case of a non-trivial in- 
put specification, identifying the source of a test can 
be surprisingly difficult especially when there is signifi- 
cant “collaboration” between individual requirements. 

An extension to our parser allows subexpressions 
within the S specification to be tagged with user de- 



fined identifiers [11], This use of identifiers is consis- 
tent with many requirements specification techniques 
now used in industry. During rewriting, the tags are 
propagated. By displaying these tags with the analysis 
results, the source of the results can be determined. 

4.7 Quantification 

Our specifications can include quantifiers. In abstrac- 
tion, a quantified subexpressions can be treated as a 
single Boolean variable for the purpose of automated 
analysis. However, we can do better than this con- 
servative approach in certain circumstances. The sub- 
stitutions described in this section can be done either 
during SFE or rewriting, or as a separate function. 

For quantified variables of types with a finite num- 
ber of members we can substitute the possible values 
for the variable, e.g., universal quantification over a 
finite set of values can be expanded into a conjunction 
of conditions. For example, given the following type 
definition and predicate declaration: 

: chocolate := Cadburys | Hersheys | Rogers; 
tastesGood : chocolate — > bool; 

the expression 

V(x : chocolate) .taste sGood(x) 
can be rewritten as: 

taste sGood{CaAh\xrys) A 
tastesGood(Hersheys) A 
tastesGood( Rogers) 

For quantified variables of infinite or uninterpreted 
types, we have experimented with methods for instan- 
tiating universally quantified variables. When the an- 
tecedent of a logical implication is a universally quan- 
tified term, the universally quantified variable can be 
instantiated by any uninterpreted constant of the ap- 
propriate type. This substitution is a form of pre- 
condition strengthening. Because (Vx.P(x)) =>■ P(a), 
we can prove (Vx.P(x)) =>■ Q by proving P(a ) =>■ Q. 
This substitution is useful as part of various analysis 
tasks such as completeness and consistency checking. 
It transforms constraints on the environment stated 
in terms of quantification into a non-quantified form 
that can be used in automated analysis. For example, 
given the following declarations and definitions, 

A, B : flight; 
env = V(/ : flight). 

-i(is-flyingJevel(f) A is-climbing{f )); 

in a specification, we use the instances of the univer- 
sally quantified environmental constraint for A and B, 


namely: 

lying Jevel(A) A is_climbing(A )) A 

lying Jevel(B) A is-climbing(B)) 

We found this form of substitution very useful for en- 
vironmental assumptions, which are often stated with 
universal quantification. 

The approach used in test generation is based on 
a test coverage point of view. The user identifies the 
type of a quantified variable, treated as a set, as either 
static or dynamic. A type is dynamic if it can be 
different in different contexts of the specification. For 
example, quantification over the “flight” type might 
be dynamic, since there can be different numbers of 
aircraft within an airspace at any given time. A type 
is static if it is not dynamic, e.g., the set of natural 
numbers is a static specification element. 

When a quantified variable has a type that is a dy- 
namic set, we consider what instances of the type 
should be analyzed to ensure adequate coverage in 
testing. This type of simplification can be performed 
in at least three modes: none, single, or all. In the 
“single” mode of coverage, for the expression: 

Vx : X. Pi(x) V P 2 (t) V ... V P n (x) 

we substitute a single value of type X , because this 
expression can be satisfied if one value has one of the 
properties P. t . For example if the type X contains a 
value c, the quantified expression above would be re- 
placed by Pi(c). In the “all” mode, we substitute n 
points, each one addressing a different Pi. Any con- 
stants introduced must be new, and free in the speci- 
fication. 

4.8 Codifying Domain Knowledge 

Domain knowledge, or environmental assumptions, 
are conditions that must be taken into account during 
analysis to disregard infeasible combinations of con- 
ditions, and simplify expressions. In system-level re- 
quirements, we found there are relatively few depen- 
dencies between conditions, and therefore these can 
be expressed concisely using quantified axioms. 

For some types of analysis, domain knowledge can 
be combined with the specification in the analysis. It 
is the antecedent of the analysis goal, or conjuncted 
with the symbolic representation of the state set to 
enforce the constraint. In these cases, the substitu- 
tion of relevant constants in the quantified expression 
described in Section 4.7 proved very useful. 

In other types of analysis, such as test generation we 
cannot combine the statements of the domain knowl- 
edge with the specification because every part of the 
output must be traceable to the inputs. For these 



cases, we identified three schemata that capture the 
form of many of the axioms that are often used: 

1. Wx.G => MutE x[Pi(i);P 2 (i);...P n (a:)] > 

2. \/x.G =>■ Subsm[P!(a:); ■ ■ -Pn(x)\, and 

3. Vx.G =£> States [Pi (a:); P 2 ( a; ); . . . P n (x)]. 

These schemata map the problem of simplifying an ex- 
pression containing elements that match the patterns 
given in the schemata list to the problem of satisfying 
the guard G for the same instance of x. For exam- 
ple, conditions that form partial orders can be defined 
using Subsm. Conditions on the right subsume con- 
ditions on the left in the Subsm list. The statement 
Va :,y,z.x < y =>■ Subsm[x < z\y < z\ captures the 
information that if k < i then i < j =>■ k < j. The op- 
tional guard G, in this case x < y, provides a means of 
converting the dependency into a standard domain for 
which the analysis tool has a decision procedure. An 
expression such as 5 < x A 10 < a:, is simplified by the 
schemata to 10 < x because it can check 5 < 10. The 
MutEx form is used to define dependencies between 
mutually exclusive conditions. The States form de- 
fines conditions that represent a set of states; exactly 
one is true. These forms, combined with the pattern- 
matching capabilities provided by the rewrite system, 
are a powerful method of allowing the user to provide 
input to the tool as domain knowledge. 

Though we found that the above approaches meet 
our needs, they have certain limitations. First, when 
there are more dependent relationships dictated by the 
environment, a formal model of the environment may 
be more concise than just axioms. Second, for more 
complex relationships it may be more efficient to pro- 
vide a specially coded decision procedure, rather than 
pattern matching and basic evaluation to simplify ex- 
pressions. 

5 Analysis Procedures 

The procedures in our toolkit are combined together 
to form analysis procedures. In this section, we de- 
scribe the procedures we have applied in examples. 
Table 1 is a partial list of the commands currently 
available in our tool. 

5.1 Generating a Satisfying Assign- 
ment 

To further one’s understanding of the meaning of a 
complicated Boolean S expression, it can be useful to 
examine a satisfying assignment for that expression. 
This analysis procedure first expands any defined sym- 
bols in the expression using symbolic functional eval- 
uation, and then constructs a Boolean abstraction of 


the expression represented as a BDD. The user chooses 
the evaluation level for SFE. Using an algorithm found 
in the Voss system due to Seger, we provide two pos- 
sible ways of producing a satisfying assignment. One 
attempts to choose as many true assignments to vari- 
ables as possible and the other has preference for false 
assignments. 


5.2 Symbolic CTL Model Checking 

Our model checking procedure takes constants with 
definitions that are 1) a CTL formula, 2) a next state 
relation, 3) an initial condition, and 4) an optional 
environmental constraint. We have a representation 
of CTL formula as an S datatype. Internally the ex- 
pression representing the CTL formula is decomposed 
to invoke procedures based on the definitions of the 
component formulae. The next state relation, initial 
condition, and environmental constraint are all evalu- 
ated using SFE, and abstracted to propositional logic 
as a BDD. The current and next state variables are 
determined for the next state relation. 

We currently have counterexample generation for 
AG and EF CTL formulae. 


5.3 Simulation 

For state machine specifications, a non-exhaustive 
form of configuration space exploration is simulation. 
The presence of uninterpreted constants in the speci- 
fication forces our simulation to be symbolic. 

Our analysis procedure does simulation based on 
the BDD representing the next state relation and con- 
straint satisfaction. The user can constrain the set of 
assignments possible for the initial state and each sub- 
sequent state using a list of conditions. A particular 
assignment to the Boolean variables is chosen at each 
step. This assignment becomes the previous config- 
uration for the next step. By choosing a particular 
assignment each time, this form of simulation does 
not encounter the state space explosion problem as in 
model checking. 

A sequence of steps may not exist that satisfies the 
listed conditions. An arbitrary choice of a particular 
state that satisfies the constraints made early in the 
simulation may result in a satisfying sequence of steps 
not being found when one does exist. An alternative, 
slightly more expensive, analysis procedure carries out 
“one-lookahead” . At each step, it chooses a configu- 
ration that satisfies the applicable constraint and has 
a next state that satisfies the next constraint in the 
list. 



Command 

Action 

%setorder <const> 

use the BDD variable order given by the 
expression list <const> 

%save_bdd <const> <fname> 

save a BDD associated with a constant in the file 

%load_bdd <const> <fname> 

load a BDD from the file into constant 

7obddsimp <const> <ret_c> 

simplify <const> using BDDs; put result in <ret_c> 

7obddsatisf ies <const> 

using BDDs, provide a satisfying assignment 

7oCtlmc <ctl> <nsr> <ic> <env> 

do symbolic CTL model checking given next state relation, 
initial condition, and environmental assumption 

7oSimulate <nsr> <c_list> 

simulate the next state relation by satisfying the 
constraint list in each step 

7ocomp <const> <env> 

do completeness check of a tabular expression 

7ocons <const> <env> 

do consistency check of a tabular expression 

7oSym <const> <env> 

do symmetry check of a two-parameter tabular expression 

7otcg <options> <const> 

produce test classes and test frames for <const> 


Table 1: Analysis Commands 


5.4 Completeness, Consistency, and 
Symmetry Checking 

We use the same criteria as Heimdahl and Leve- 
son [19], and Heitmeyer et al. [21] for the complete- 
ness and consistency of tabular specifications. Com- 
pleteness analysis evaluates the expression consisting 
of the disjunction of the table’s rows using SFE1. After 
Boolean abstraction, we check if the expression is a 
tautology. If not, we reverse the abstraction, and use 
unexpansion to produce results in a column format, 
enumerating the cases that are not covered in the ta- 
ble. This presentation is possible because SFE main- 
tains the unevaluated versions of expressions, and it 
addresses some of the problems identified by Heimdahl 
in tracing the source of inconsistencies through nested 
tables where the output is completely expanded [18], 

A similar procedure is carried out for consistency 
checking, where all pairs of columns are checked for 
overlap. 

For symmetry checking, the analysis procedure con- 
structs two versions of a two-parameter table with the 
parameters swapped, and checks if the two tables are 
the same. 

5.5 Test Generation 

System-level requirements-based test generation is an 
analysis that makes extensive use of rewriting. The 
rewrite rules used were verified using HOL. The S 
specification is assumed to be a relation between the 
stimuli and responses of the system. 

After unfolding the specification to the desired 
level of detail, the resulting formula is transformed 
into its logically equivalent Test Class Normal Form 
(TCNF) [10, 13]. The TCNF is a conjunction of test 


classes, which describe particular stimulus/response 
behaviours as implications with the stimuli in the an- 
tecedent and responses in the consequent. 

The antecedents of the test classes are rewritten fur- 
ther to reduce the size of quantified subexpressions. 
Choices (disjuncts) within an antecedent represent dif- 
ferent test descriptions, referred to as test frames. A 
test frame is a test class that has no choice in the 
antecedent (other than instantiation) . Domain knowl- 
edge is applied to simplify the test frames, and remove 
any that are infeasible. 

Test frames are the results of the analysis, and are 
logical consequences of the given specification. Test 
frames are selected to cover the Boolean function rep- 
resented by the test class antecedent using BDDs. The 
selection of test frames is determined by one of several 
coverage criteria chosen by the user. 

6 Conclusions 

We have described a lightweight approach for applying 
automated analysis techniques to higher-order logic 
specifications. To support this approach we have cre- 
ated utilities that manipulate higher-order logic ex- 
pressions in truth-preserving ways. These utilities 
handle the features of a logic, such as uninterpreted 
constants and quantification, in evaluation and ab- 
straction. 

We have demonstrated that a common core of utili- 
ties allows us to implement diverse analysis procedures 
such as test generation, and model checking. The com- 
mon toolkit facilitates re-use of code and extension 
of the suite of analysis procedures with new methods 
such as symmetry checking and constraint-based sim- 
ulation. We have also shown methods particular to 




embedded notations can be created such as the com- 
pleteness and consistency analysis of tables. 

Two other innovations of our approach are: we allow 
users to control performance factors such as BDDs in 
terms of the language of the specification; and through 
the analysis process we maintain information that pro- 
duces readable, traceable results in the language of the 
specification. 

Space does not permit us to describe the real-world 
examples that we have specified and analyzed using 
our tools. Examples include an aeronautical telecom- 
munications network (ATN) [2, 7], a separation min- 
ima for aircraft [9, 12], a small heating system [7], a 
steam boiler control system [13], and parts of a pro- 
prietary air traffic management system [14]. These 
examples are non-trivial. For example, the parame- 
terized formal ATN statechart specification is approx- 
imately 43 pages. The expanded S representation of 
the ATN next state relation consists of 52 076 nodes 
in a canonical form. 

In the future, we would like to explore how other 
automated abstraction techniques can be used in our 
framework. For example, less conservative results can 
be achieved by abstracting to a variant of first-order 
logic. We would like to explore decomposition strate- 
gies to lessen the state space explosion problem. Our 
approach, which uses the same specification language 
as a high-powered tool where these strategies can be 
verified, allows experts to hard code their verification 
method to make it accessible to non-experts. 
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Abstract 

To become practical for assurance, automated for- 
mal methods must be made more scalable, automatic, 
and cost-effective. Such an increase in scope, scale, au- 
tomation, and utility can be derived from an emphasis on 
a systematic separation of concerns during verification. 
SAL (Symbolic Analysis Laboratory ) attempts to address 
these issues. It is a framework for combining differ- 
ent tools to calculate properties of concurrent systems. 
The heart of SAL is a language, developed in collabora- 
tion with Stanford, Berkeley, and Verimagjor specifying 
concurrent systems in a compositional way. Our instan- 
tiation of the SAL framework augments PVS with tools 
for abstraction, invariant generation, program analysis 
(such as slicing), theorem proving, and model checking 
to separate concerns as well as calculate properties ( i.e., 
perform symbolic analysis) of concurrent systems. We 
describe the motivation, the language, the tools, their 
integration in SAL/PVS, and some preliminary experi- 
ence of their use. 


1 Introduction 

To become practical for debugging, assurance, and 
certification, formal methods must be made more cost- 
effective. Incremental improvements to individual ver- 
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ification techniques will not suffice. It is our basic 
premise that a significant advance in the effectiveness 
and automation of verification of concurrent systems is 
possible by engineering a systematic separation of con- 
cerns through a truly integrated combination of static 
analysis, model checking, and theorem proving tech- 
niques. A key idea is to change the perception (and im- 
plementation) of model checkers and theorem provers 
from tools that perform verifications to ones that calcu- 
late properties such as slices, abstractions and invariants. 
In tins way, big problems are cut down to manageable 
size, and properties of big systems emerge from those of 
reduced subsystems obtained by slicing, abstraction, and 
composition. By iterating through several such steps, it 
becomes possible to incrementally accumulate proper- 
ties that eventually enable computation of a substantial 
new property — which in turn enables accumulation of 
further properties. By interacting at the level of proper- 
ties and abstractions, multiple analysis tools can be used 
to derive properties that are beyond the capabilities of 
any individual tool. 

SAL (Symbolic Analysis Laboratory) addresses 
these issues. It is a framework for combining dif- 
ferent tools for abstraction, program analysis, theorem 
proving, and model checking toward the calculation of 
properties (symbolic analysis) of concurrent systems ex- 
pressed as transition systems. The heart of SAL is an 
intermediate language, developed in collaboration with 
Stanford, Berkeley, and Verimag for specifying concur- 
rent systems in a compositional way. This language will 
serve as the target for translators that extract the tran- 
sition system description for popular programming lan- 
guages such as Esterel, Java, or Verilog. The intermedi- 
ate language also serves as a common description from 
which different analysis tools can be driven by translat- 
ing file intermediate language to the input format for the 
tools and translating the output of these tools back to the 
SAL intermediate language. 

This paper is structured as follows. In Section 2 we 



describe the motivation and rationale behind the design 
of the SAL language and give an overview of its main 
features. The main part. Section 3, describes SAL com- 
ponents including slicing, invariant generation, abstrac- 
tion, model checking, simulation, and theorem proving 
together with their integration into the SAL toolset. Sec- 
tion 4 concludes with some remarks. 

2 The SAL Common Intermediate Lan- 
guage 

Mechanized formal analysis starts from a description 
of the problem of interest expressed in the notation of 
the tool to be employed. Construction of this descrip- 
tion often entails considerable work: first to recast the 
system specification from its native expression in C, Es- 
terel, Java, SCR, UML, Verilog, or whatever, into the 
notation of the tool concerned, then to extract the part 
that is relevant to the analysis at hand, and finally to re- 
duce it to a form that the tool can handle. If a second tool 
is to be employed for a different analysis, then a second 
description of the problem must be prepared, with con- 
siderable duplication of effort. With m source languages 
and n tools, we need m*n translators. This situation nat- 
urally suggests use of a common intermediate language, 
where the numbers of tools required could be reduced to 
m + n translators. 

The intermediate language must serve as a medium 
for representing the state transition semantics of a sys- 
tem described in a source language such as Java or Es- 
terel. It must also serve as a common representation 
for driving a number of back-end tools such as theorem 
provers and model checkers. A useful intermediate lan- 
guage for describing concurrent systems must attempt to 
preserve both the structure and meaning of the original 
specification while supporting a modular analysis of the 
transition system. 

For these reasons, the SAL intermediate language is a 
rather rich language. In the sequel, we give an overview 
of the main features of the SAL type language, the ex- 
pression language, the module language, and the con- 
text language. For a precise definition and semantics of 
the SAL language, including comparisons to related lan- 
guages for expressing concurrent systems, see [31], 

The type system of SAL supports basic types such 
as booleans, scalars, integers and integer subranges, 
records, arrays, and abstract datatypes. Expressions 
are strongly typed. The expressions consist of con- 
stants, variables, applications of Boolean, arithmetic, 
and bit-vector operations (bit-vectors are just arrays of 
Booleans), and array and record selection and updates. 
Conditional expressions are also part of the expression 


mutex : CONTEXT = 

BEGIN 

PC: TYPE = {trying, criti- 
cal, sleeping} 

mutex [tval : boolean] : MODULE = 
BEGIN 

INPUT pc2 : PC, x2 : boolean 
OUTPUT pci: PC, xl : boolean 

INITIALIZATION 

TRUE --> pci = sleeping; 
xl = tval 

TRANSITION 

pci = sleeping 

--> pci' = trying; 

xl' = (x2=tval) 

[] 

pci = trying AND 
(pc2=sleeping OR xl= (x2/=tval) ) 
--> pci' = critical 

[] 

pci = critical 

--> pci' = sleeping; 
xl' = (x2=tval) 

END 

system: MODULE = 

HIDE xl , x2 
(mutex [FALSE] 

| | RENAME pc2 TO pci, 
x2 TO xl, 
pci TO pc2, 
xl TO x2 
mutex [TRUE] ) 

mutualExclusion : THEOREM 
system | - 

AG (NOT (pcl=critical 

AND pc2=critical ) ) 

eventual lyl : LEMMA 

system |- EF (pcl=critical ) 
eventually2 : LEMMA 

system |- EF (pc2=critical ) 

END 


Figure 1. Mutual Exclusion 



language and user-defined functions may also be intro- 
duced. 

A module is a self-contained specification of a tran- 
sition system in SAL. Usually, several modules ate col- 
lected in a context. Contexts also include type and con- 
stant declarations. A transition system module consists 
of a state type, an initialization condition on tins state 
type, and a binary transition relation of a specific form 
on the state type. The state type is defined by four pah- 
wise disjoint sets of input, output, global, and local vari- 
ables. The input and global variables are the observed 
variables of a module and the output, global, and local 
variables are the controlled variables of the module. It 
is good pragmatics to name a module. This name can be 
used to index the local variables so that they need not be 
renamed during composition. Also, the properties of the 
module can be indexed on the name for quick lookup. 

Consider, for example, the SAL specification of a 
variant of Peterson’s mutual exclusion algorithm in Fig- 
ure 1. Fie re the state of the module consists of the 
controlled variables corresponding to its own program 
counter pci and boolean variable xl, and the observed 
variables are the corresponding pc 2 and x2 of the other 
process. 

The transitions of a module can be specified variable- 
wise by means of definitions or transition-wise by 
guarded commands. Ffenceforth, primed variables X ' 
denote next-state variables. A definition is of the form 
X = f ( Y , Z ) . Both the initializations and transitions 
can also be specified as guarded assignments. Each 
guarded command consists of a guarded formula and an 
assignment part. The guard is a boolean expression in 
the current controlled (local, global, and output) vari- 
ables and current-state and next-state input variables. 
The assignment part is a list of equalities between a left- 
hand side next-state variable and a right hand side ex- 
pression in both current-state and next-state variables. 

Parametric modules allow the use of logical (state- 
independent) and type parameterization in the definition 
of modules. Module mutex in Figure 1, for example, is 
parametric in the Boolean tval. Furthermore, mod- 
ules in SAL can be combined by either synchronous 
composition | | , or asynchronous composition [] . Two 
instances of the mutex module, for example, are con- 
joined synchronously to form a module called system 
in Figure 1. This combination also uses hiding and re- 
naming. Output and global variables can be made local 
by the HIDE construct. In order to avoid name clashes, 
variables in a module can be renamed using the RENAME 
construct. 

Besides declaring new types, constants, or modules, 
SAL also includes constructs for stating module prop- 
erties and abstractions between modules. CTL formulas 


are used, for example, in Figure 1 to state safety and live- 
ness properties about the combined module system. 

The form of composition in SAL supports a com- 
positional analysis in the sense that any module prop- 
erties expressed in linear-time temporal logic or in the 
more expressive universal fragment of CTL* are pre- 
served through composition. A similar claim holds for 
asynchronous composition with respect to stuttering in- 
variant properties where a stuttering step is one where 
the local and output variables of the module remain un- 
changed. 

Because SAL is an environment where theorem prov- 
ing as well as model checking is available, absence of 
causal loops in synchronous systems is ensured by gen- 
erating proof obligations, rather than by more restrictive 
syntactic methods as in other languages. Consider the 
following definitions: 

X = IF A THEN NOT Y ELSE C END IF 

Y = IF A THEN B ELSE X END IF 

This pair of definitions is acceptable in SAL because we 
can prove that X is causally dependent on Y only when 
A is true, and vice-versa only when it is false — hence 
there is no causal loop. In general, causality checking 
generates proof obligations asserting that the conditions 
that can trigger a causal loop are unreachable. 

3 SAL Components 

SAL is built around a blackboard architecture cen- 
tered around the SAL intermediate language. Different 
backend tools operate on system descriptions in the in- 
termediate language to generate properties and abstrac- 
tions. The core of the SAL toolset includes the usual 
infrastructure for parsing and type-checking. It also al- 
lows integration of translators and specialized compo- 
nents for computing and verifying properties of transi- 
tion systems. These components are loosely coupled 
and communicate through well-defined interfaces. An 
invariant generator may expect, for example, various ap- 
plication specific flags and a SAL base module, and it 
generates a corresponding assertion in the context lan- 
guage together with a justification of the invariant. The 
SAL toolset keeps track of the dependencies between 
generated entities, and provides capabilities similar to 
proof-chain analysis in theorem proving systems like 
PVS. 

The main ingredients of the SAL toolset are special- 
ized components for computing and verifying properties 
of transition systems. Currently, we have integrated var- 
ious components providing basic capabilities for analyz- 
ing SAL specifications, including 



• Validation based on theorem proving, model check- 
ing, and animation; 

• Abstraction and invariant generation; 

• Generation of counterexamples; 

• Slicing. 

We describe these components hi more detail below. 

3.1 Backend translations 

We have developed translators from the SAL inter- 
mediate language to PVS, SMV, and Java for validat- 
ing SAL specifications by means of theorem proving 
(in PVS), model checking (in SMV), and animation (in 
Java). These compilers implement shallow structural 
embeddings [26] of the SAL language; that is, SAL 
types and expressions are given a semantics with re- 
spect to a model defined by the logic of the target lan- 
guage. The compilers performs a limited set of semantic 
checks. These checks mainly concern the use of state 
variables. More complex checks, as for example type 
checking, are left to the verification tools. 

3.1.1 Theorem Proving: SAL to PVS 

PVS is a specification and verification environment 
based on higher-order logic [27]. SAL contexts con- 
taining definitions of types, constants, and modules, are 
translated into PVS theories. This translation yields a se- 
mantics for SAL transition systems. Modules are trans- 
lated as parametric theories containing a record type to 
represent the state type, a predicate over states to rep- 
resent the initialization condition, and a relation over 
states to represent the transition relation. Figure 2 de- 
scribes a typical translation of a SAL module in PVS. 
Notice that initializations as well as transitions may be 
nondeterm inistic. 

Compositions of modules are embedded as logical 
operations on the transition relations of the correspond- 
ing modules: disjunction for the case of asynchronous 
composition, conjunction for the case of synchronous 
composition. Hiding and renaming operations are mod- 
eled as morphisms on the state types of the modules. 
Logical properties are encoded via the temporal logic of 
the PVS specification language. 

3.1.2 Model Checking: SAL to SMV 

SMV is a popular model checker with its own system 
description language [25], SAL modules are mapped to 
SMV modules. Type and constant definitions appearing 


module [para : Parameters] : THEORY 
BEGIN 

State : TYPE = [# 

input : InputVars, 
output : OutputVars , 
local : LocalVars 

#] 

state, next : VAR State 

initialization (state) :boolean = 
(guard_init_l AND 
output (state) = ... AND 
local (state) = . . . ) 

OR . . . OR (guard_init_n AND . . . ) 

transitions ( state , next) : boolean = 
(guard_trans_l AND 
output (next) = 

output ( state) WITH [...] 
local (next) = 

local (state) WITH [... ]) 

OR ... OR 

(guard_trans_m AND . . . ) 

OR 

(NOT guard_trans_l AND . . . AND 
NOT guard_trans_m AND 
output (next) = output ( state) 
local (next) = local ( state ) ) 

Figure 2. A SAL module in PVS 

in SAL contexts are directly expanded in the SMV spec- 
ifications. Output and local variables are translated to 
variables in SMV. Input variables are encoded as param- 
eters of SMV modules. 

The nondeterministic assignment of SMV is used to 
capture the arbitrary choice of an enabled SAL transi- 
tion. Roughly speaking, two extra variables are intro- 
duced. The hist is assigned nondeterministically with a 
value representing a SAL transition. The guard of the 
transition represented by this variable is the first guard 
to be evaluated. The second variable loops over all tran- 
sitions starting from the chosen one until it finds a tran- 
sition which is enabled. This mechanism assures that 
every transition satisfying the guard has an equal chance 
to being hied in the hrst place. Composition of SAL 
modules and logical properties are directly translated via 
the specification language of SMV. 

3.1.3 Animation: SAL to Java 

Animation of SAL specifications is possible via compi- 
lation to Java. However, not all the features of the SAL 



language are supported by the compiler. In particular; 
the expression language that is supported is limited to 
that of Java. For example, only integers and booleans are 
accepted as basic types. Elements of enumeration types 
are translated as constants and record types are repre- 
sented by classes. 

The state type of a SAL module is represented by 
a class containing fields for the input, output, and lo- 
cal variables. In order to simulate the nondeterminism 
of the initialization conditions, we have implemented a 
random function that arbitrary chooses one of the initial- 
ization transition satisfying the guard. 

Each transition is translated as a Java thread class. 
At execution time, all the threads share the same state 
object. We assume that the Java virtual Machine is non- 
deterministic with respect to execution of threads. The 
main function of the Java translation creates one state 
object and passes the object as an argument to the thread 
object constructors. It then starts all the threads. Safety 
properties are encoded by using the exception mecha- 
nism of Java, and are checked at run time. 

3.1.4 Case Study: Flight Guidance System 

Mode confusion is a concern in aviation safety. It oc- 
curs when pilots get confused about the actual states of 
the flight deck automation. NASA Langley conducts 
research to formally characterize mode confusion situ- 
ations in avionics systems, hr particular, a prototype 
of a Flight Guidance System (FGS) has been selected 
a case study for the application of formal techniques to 
identify mode confusion problems. FGS has been spec- 
ified in various formalisms (see [23] for a comprehen- 
sive list of related work). Based on work by Luttgen 
and Carreno, we have developed a complete specifica- 
tion of FGS in SAL. The specification has been auto- 
matically translated to SMV and PVS, where it has been 
analyzed. We did not experience any significant over- 
head in model checking translated SAL models com- 
pared to hand-coded SMV models. This case study is 
available at http : / /www . lease . edu . /~munoz / 
sources . html. 

3.2 Invariant Generation 

An invariant of a transition system is an assertion — 
a predicate on the state — that holds of every reachable 
state of the transition system. An inductive invariant is 
a assertion that holds of the initial states and is preserved 
by each transition of the transition system. An inductive 
invariant is also an invariant but not every invariant is 
inductive. 

Let SP(T, <j>) denote the formula that represents the 
set of all states that can be reached from any state in <j> 


via a single transition of the system T, and © denote the 
formula that denotes the initial states. A formula <p is 
an inductive invariant for the transition system T if (i) 

© — y 4>\ (ii) sp(T , <p) — r 0. 

We recall that for a given transition system T and 
a set of states described by formula (j> , the notation 
SP(T, <j>) denotes the formula that characterizes all 
states reachable from states <i> using exactly one transi- 
tion from T. If 0 denotes the initial state, then it follows 
from the definition of invariants that any fixed-point of 
the operator F(<j>) = SP(T, <j>) V 0 is an invariant. 

Notice that the computation of strongest postcondi- 
tions introduces existentially quantified formulas. Due 
to novel theorem proving techniques in PVS2.3 that are 
based on the combination of a set of ground decision 
procedures and quantifier elimination we are able to ef- 
fectively reason about these formulas in many interest- 
ing cases. 

It is a simple observation that not only is the greatest 
fixed point of the above operator an invariant, but ev- 
ery intermediate (pi generated in an iterated computation 
procedure of greatest fixed point also is an invariant. 

<po : true 

<Pi+ 1 : SP (T,&)V© 

A consequence of the above observation is that we do 
not need to detect when we have reached a fixed point in 
order to output an invariant. 

As a teclmical point about implementation of the 
above greatest fixed point computation in SAL, we men- 
tion that we break up the (possibly infinite) state space 
of the system into finitely many (disjoint) control states. 
Thereafter, rather than working with the global invari- 
ants cpi, we work with local invariants that hold at par- 
ticular' control states. The iterative greatest fixed point 
computation can now be seen as a method of generating 
invariants based on affirmation and propagation [6], 

Note that rather than computing the greatest fixed 
point, if we performed the least fixed point computation, 
we would get the strongest invariant for any given sys- 
tem. The problem with least fixed points is that then 
computation does not converge as easily as those of 
greatest fixed points. Unlike greatest fixed points, the 
intermediate predicates in the computation of the least 
fixed point are not invariants. We are currently investi- 
gating approaches based on widening to compute invari- 
ants in a convergent manner using least fixed points [8], 

Hie techniques described so far are noncomposi- 
tional since they examine all the transitions of the given 
system. We use a novel composition rule defined in [29] 
allowing local invariants of each of the modules to be 
composed into global invariants for the whole system. 



This composition rule allows us to generate stronger in- 
variants than the invariants generated by the techniques 
described hi [6,7], The generated invariants allows us to 
obtain boolean abstractions of the analyzed system using 
the incremental analysis techniques presented in [29], 

3.3 Slicing 

Program analyses like slicing can help remove code 
irrelevant to the property under consideration from the 
input transition system which may result in a reduced 
state-space, thus easing the computational needs of sub- 
sequent fonnal analysis effoits. Our slicing tool [18] 
accepts an input transition system which may be syn- 
chronously or asynchronously composed of multiple 
modules written in SAL and the property under verifica- 
tion. The property under verification is converted into a 
slicing criterion and the input transition system is sliced 
with respect to this slicing criterion. The slicing crite- 
rion is merely a set of local/output variables of a subset 
of the modules in the input SAL program that are not 
relevant to the property. The output of the slicing al- 
gorithm is another SAL program similarly composed of 
modules wherein irrelevant code manipulating irrelevant 
variables from each module has been sliced out. For ev- 
ery input module there will be an output module, empty 
or otherwise. In a nutshell the slicing algorithm does 
a dependency analysis of each module and computes 
backward transitive closure of the dependencies. This 
transitive closure would take into consideration only a 
subset of all transitions in the module. We call these 
transitions observable and the remaining transitions are 
called t or silent transitions. We replace silent transi- 
tions with skips. 

We are currently investigating reduction techniques 
that are simpler than slicing and also ones that are more 
aggressive. One example is the cone-of-mfluence re- 
duction where the slicing criterion is a set of variables 
V, and the reduction computes a transition system that 
includes all the variables in the transitive closure of V 
given by the dependencies between variables [21], In 
comparison with slicing, the cone-of-mfluence reduc- 
tion is insensitive to control and is therefore easier to 
compute but generally not as efficient at pruning irrele- 
vance. Slicing preserves program behavior with respect 
to the slicing criterion. One could obtain a more dra- 
matic reduction by admitting slices that admitted more 
behaviors by introducing nondeterminism. Such aggres- 
sive slicing would be needed for example to abstract 
away from the internal behavior of a transition system 
within its critical section for the purpose of verifying 
mutual exclusion. Slicing for concurrent systems with 
respect to temporal properties has been investigated by 


Dwyer and Hatcliff [16], 

3.4 Connecting InVeSt with SAL 

So far we have described specialized SAL compo- 
nents that provide core features for the analysis of con- 
current systems, but we have also integrated the stand- 
alone InVeSt [5] into the SAL framework. Besides com- 
positional techniques for constructing abstraction and 
features for generating counterexamples from failed ver- 
ification attempts, InVeSt introduces alternative methods 
for invariant generation to SAL. InVeSt not only serves 
as a backend tool for SAL but also has been connected 
to the IF laboratory [10], Aldebaran [9], TGV [17] and 
Kronos [15]. 

The salient feature of InVeSt is that it combines the 
algorithmic with the deductive approaches to program 
verification in two different ways. First, it integrates the 
principles underlying the algorithmic (e.g. [11,28]) and 
the deductive methods (e.g. [24]) in the sense that it uses 
fixed point calculation as in the algorithmic approach but 
also the reduction of the invariance problem to a set of 
first-order formulas as in the deductive approach. Sec- 
ond, it integrates the theorem prover PVS [27] with the 
model checker SMV [25] through the automatic com- 
putation of finite abstractions. That is, it provides the 
ability to automatically compute finite abstractions of 
infinite state systems which are then analyzed by SMV 
or, alternatively, by the model checker of PVS. Further- 
more, InVeSt supports the proof of invariance proper- 
ties using the method based on induction and auxiliary 
invariants (e.g. [24]) as well as a method based on ab- 
straction techniques [2, 12-14,21,22], InVeSt uses PVS 
as a backend tool and depends heavily on its theorem 
proving capabilities for deciding the myriad verification 
conditions. 

3.4.1 Abstraction 

InVeSt provides also a capability that computes an ab- 
stract system from a given concrete system and an ab- 
straction function. The method underlying this tech- 
nique is presented in [4], The main features of this 
method is that it is automatic and compositional. It com- 
putes an abstract system S a = 5* || • • • || .S'", for a 
given system S = S 1 || • • • || S n and abstraction func- 
tion a, such that S simulates S a is guaranteed by the 
construction. Hence, by known preservation results, if 
S a satisfies an invariant <p then S satisfies the invari- 
ant a -1 (p). Since the produced abstract system is not 
given by a graph but in a programming language, one 
still can apply all the known methods for avoiding the 
state explosion problem while analyzing S a . Moreover, 



it generates ail abstract system which has the same struc- 
ture as the concrete one. This gives the ability to apply 
further abstractions and techniques to reduce the state 
explosion problem and facilitates the debugging of the 
concrete system. The computed abstract system is op- 
tionally represented in the specification language of PVS 
or in that of SMV. 

The basic idea behind our method of computing ab- 
stractions is simple. In order to construct an abstrac- 
tion of S, we construct for each concrete transition r c 
an abstract transition r a . To construct r a we proceed by 
elimination starting from the universal relation, which 
relates every abstract state to every abstract state, and 
eliminate pairs of abstract states in a conservative way, 
that is, it is guaranteed that after elimination of a pah the 
obtained transition is still an abstraction of r c . To check 
whether a pair (o, o') of abstract states can be eliminated 
we have to check that the concrete transition t c does not 
lead from any state c with a(c) = a to any state c' with 
a(c') = o'. This amounts to proving a Hoare triple. The 
elimination method is in general too complex. There- 
fore, we combine it with three teclmiques that allow 
many fewer Hoare triples to be checked. These tech- 
niques are based on partitioning the set of abstract vari- 
ables, using substitutions, and a new preservation result 
which allows to use the invariant to be proved during the 
construction process of the abstract system. 

We implemented our' method using the theorem 
prover PVS [27] to check tire Hoare triples generated by 
the elimination method. The first-order formulas corre- 
sponding to these Hoare triples are constructed automat- 
ically and a strategy that is given by the user is applied. 
In [1] we developed also a general analysis methodol- 
ogy for heterogeneous infinite-state models, extended 
automata operating on variables which may range over 
several different domains, based on combining abstrac- 
tion and symbolic reachability analysis. 

3.4.2 Generation of Invariants 

There are two different way to generate invariants in 
InVeSt. First, we use calculation of pre-fixed points 
by applying the body of the backward procedure a fi- 
nite number of times and use teclmiques for the auto- 
matic generation of invariants (cf. [3]) to support the 
search for auxiliary invariants. The tool provides strate- 
gies which allow derivation of local invariants, that is, 
predicates attached to control locations and which are 
satisfied whenever the computation reaches the corre- 
sponding control point. hiVeSt includes strategies for 
deriving local invariants for sequential systems as well 
as a composition principle that allows combination of 
invariants generated for sequential systems to obtain in- 


variants of a composed system. Consider a composed 
system S\ || .Sp and control locations p and 1 2 of .S) 
and S2 , respectively. Suppose that we generated the lo- 
cal invariants P] and P 2 at /, and p, respectively. Let us 
call P{ interference independent, if does not contain a 
free variable that is written by Sj with j f i. Then, de- 
pending on whether Pj is interference independent we 
compose the local invariants P, and P 2 to obtain a lo- 
cal invariant at (p , ) as follows: if P t is interference 

independent, then we can affirm that P 2 is an invariant 
at (/] , p) and if both Pi and P 2 are interference depen- 
dent, then Pj VP 2 is an invariant at (Zi , p). This compo- 
sition principle proved to be useful in the examples we 
considered. However, examples showed that predicates 
obtained by this composition principle can become very 
large. Therefore, we also consider the alternative option 
where local invar iants are not composed until they are 
needed in a verification condition. Tims, we assign to 
each component of the system two lists of local invari- 
ants. The first corresponds to interference independent 
local invariants and the second to interference dependent 
ones. Then, when a verification condition is considered, 
we use heuristics to determine which local invariants are 
useful when discharging the verification condition. A 
useful heuristic concerns the case when the verification 
condition is of the form (pc(l) = p Apc(2) = p) => <fi, 
where pel 1 ) = l\ A pc(2) = / 2 asserts that computation 
is at the local control locations 1 1 and p. In this case, we 
combine the local invariants associated to p and p and 
add the result to the left hand side of the implication. 

Second, we use abstraction generating invariants at 
the concrete level: Let <S ai the result of the abstrac- 
tion of a concrete system S, the set of reachable states 
denoted by Reach(S ai ) is an invariant of S ai (the 
strongest one including the initial configurations in fact). 
We developed a method that extract the fonnula which 
characterizes the reachable states from the BDD. Hence, 
op 1 ( Reach(S ai )) is an invariant of the concrete model 
S. This invariant can be used to strengthen ip and show 
that it is an invariant of S. 

3.4.3 Analysis of Counterexamples 

The generation of the abstract system is completely au- 
tomatic and compositional as we consider transition by 
transition. Thus, for each concrete transition we obtain 
an abstract transition (which might be nondetenninistic). 
This is a very important property of our method, since it 
enables the debugging of the concrete system or alter- 
natively enhancing the abstraction function. Indeed, the 
constructed abstract system may not satisfy the desired 
property, for three possible reasons: 

1 . The concrete system does not satisfy the invariant. 



2. The abstraction function is not suitable for proving 
the invariant, or 

3. The proof strategies provided are too weak. 

Now, a model checker such as SMV provides a trace as 
a counterexample, if the abstract system does not satisfy 
the abstract invariant. Since we have a clear correspon- 
dence between abstract and concrete transitions, we can 
examine the trace and find out which of the three rea- 
sons listed above is the case. In particular if the concrete 
system does not satisfy the invariant then we can trans- 
form the trace given by SMV to a concrete trace, thus 
generating a concrete counterexample. 

3.5 Predicate/Boolean Abstraction 

In addition to the InVeSt abstraction mechanisms, we 
implemented boolean abstraction of SAL specifications. 
We use file boolean abstraction scheme defined in [19] 
that uses predicates over concrete variables as abstract 
variables to abstract infinite or large state systems into 
finite state systems analyzable by model checking. The 
advantage of using boolean abstractions can be summa- 
rized as follows: 

• Any abstraction to a finite state system can be ex- 
pressed as a boolean abstraction. 

• The abstract transition relation can be repre- 
sented symbolically using Binary Decision Dia- 
gram (BDDs). Tlius, efficient symbolic model 
checking [25] can be effectively applied. 

• We have defined in [30] an efficient algorithm for 
the construction of boolean abstractions. We also 
designed an efficient refinement technique that al- 
lows us to refine automatically an already con- 
structed abstraction until the property of interest is 
proved or a counter-example is generated. 

• Abstraction followed by model checking and suc- 
cessive refinement is an efficient and more pow- 
erful alternative to invariant generation techniques 
such as the ones presented in [6,7], 

3.5.1 Automatic Construction of Boolean Abstrac- 
tions 

The automatic abstraction module takes as input a SAL 
basemodule and a set of predicates defining the boolean 
abstraction. Using the algorithm in [30] we automati- 
cally construct the corresponding abstract transition sys- 
tem. This process relies heavily on the PVS decision 
procedures. 


INPUT x: integer 
OUTPUT y, z: integer 


INITIALIZATION 

TRUE --> INIT(x) = 0; 

INIT(y) = 0; 
INIT(z) = y; 


TRANSITION 

NOT(x >0) --> y' = y + 1 
[] z > 0 --> z' = y - I# y' = 0 


Figure 3. Concrete Module. 


Figure 3 and 4 display a simple SAL module and its 
abstraction where the boolean variables Bl, B2 and B3 
correspond to the predicates x > 0, y > 0, and 3 > 0. 
Notice that the assignment to B3 is nondeterministically 
chosen from the set { T RUE , FALSE}. 


INPUT Bl: boolean 
OUTPUT B2,B3: boolean 


INITIALIZATION 

TRUE --> INIT(Bl) 
INIT (B2 ) 
INIT (B3 ) 


FALSE ; 
FALSE ; 
FALSE ; 


TRANSITION 

NOT (Bl ) --> B2'=F 

[] B3 --> B2 ' =T , B3 ' = { TRUE, FALSE } 


Figure 4. Abstract Module. 


3.5.2 Explicit Model Checking 

Finite-state SAL modules can be translated to SMV for 
model checking as explained above. However, model 
checkers usually do not allow to access their internal 
data structures where intermediate computation steps of 
the model-checking process can be exploited. For tins 
reason, we implemented an efficient explicit-state model 
checker for SAL systems obtained by boolean abstrac- 
tion. The abstract SAL description is translated into 
an executable Lisp code that performs the explicit state 
model checking procedure allowing us to explore about 



twenty thousand states a second. This procedure builds 
an abstract state graph that can be exploited for further 
analysis. Furthermore, additional abstractions can be 
applied on the fly while the abstract state graph is be- 
ing built. 

3.5.3 Automatic Refinement of Abstractions 

When model checking fails to establish the property of 
interest, we use the results developed in [29, 30] to de- 
cide whether the constructed abstraction is too coarse 
and needs to be refined, or that the property is violated 
in the concrete system and that the ge nerated counter- 
example corresponds indeed to an execution of the con- 
crete system violating the property. This is done by ex- 
amining the generated abstract state graph. The refine- 
ment technique computes the precondition to a transition 
where nondeterministic assignments occur. The precon- 
ditions corresponding to file cases where the variables 
get either TRUE or FALSE define two predicates that are 
used as new abstract variables. The following transition 
from the example 

B3 --> B2 ' =TRUE , B3 ' = {TRUE, FALSE} 

can be automatically refined to 

B3 B2 ' =TRUE , B3 ' =B4 , 

B4 ' =FALSE , B5 ' = FALSE 

where B4 and B5 correspond to the predicates y=l and 
y>l, respectively. 

4 Conclusions 

SAL is a tool that combines techniques from static 
analysis, model checking, and theorem proving in a truly 
integrated environment. Currently, its core is realized as 
an extension of the PVS system and has a well-defined 
interface for coupling specialized analysis tools. So 
far, we have been focusing on developing and connect- 
ing back-end tools for validating SAL specifications by 
means of animation, theor em proving, and model check- 
ing, and also for computing abstractions, slices, and in- 
variants of SAL modules. There are as yet no automated 
translators into the SAL language. Primary candidates 
are translators for source languages such as Java, Ver- 
ilog, Esterel, Statecharts, or SDL. Since SAL is an open 
system with well-defined interfaces, however, we hope 
others will write those if the rest of the system proves 
effective. 

We are currently completing the implementation of 
the SAL prototype which includes a parser, typechecker, 
a slicer, an invariant generator, the connection to InVeSt, 


and translators to SMV and PVS. We expect to release 
the prototype SAL system in mid-2000. 

Although our experience with file combined power of 
several forms of mechanized formal analysis in the SAL 
system is still rather limited, we predict that proofs and 
refutations of concurrent systems that currently require 
significant human effort will soon become routine cal- 
culations. 

References 

[1] P. A. Abdulla, A. Annichini, S. Bensalem, A. Bouajjani, 
P. Habermehl, and Y. Lakhnech. Verification of infinite- 
state systems by combining abstraction and reachability 
analysis. In Halbwachs and Peled [20], pages 146-159. 

[2] S. Bensalem, A. Bouajjani, C. Loiseau, and J. Sifakis. 
Property preserving simulations. In G. v. Bochmann and 
D. K. Probst, editors, Computer Aided Verification’ 92, 
volume 663 of LNCS, pages 260-273. Springer- Verlag, 
1992. 

[3] S. Bensalem and Y. Lakhnech. Automatic generation of 
invariants. Formal Methods in System Design, 15(1):75- 
92, July 1999. 

[4] S. Bensalem, Y. Lakhnech, and S. Owre. Computing 
abstractions of infinite state systems automatically and 
compositionally. In A. J. Hu and M. Y. vardi, editors, 
Computer Aided Verification, volume 1427 of LNCS, 
pages 319-331. Springer- Verlag, 1998. 

[5] S. Bensalem, Y. Lakhnech, and S. Owre. InVeSt: A 
tool for the verification of invariants, hi A. J. Hu and 
M. Y. vardi, editors, Computer Aided Verification, vol- 
ume 1427 of LNCS, pages 505-510. Springer- Verlag, 
1998. 

[6] S. Bensalem, Y. Lakhnech, and H. Sai'di. Powerful tech- 
niques for the automatic generation of invariants. In 
R. Alur and T. A. Henzinger, editors, Computer-Aided 
Verification, CAV ’96, volume 1102 of Lecture Notes in 
Computer Science, pages 323-335, New Brunswick, NJ, 
July/Aug. 1996. Springer- Verlag. 

[7] N. Bjpmer, I. A. Browne, and Z. Manna. Automatic gen- 
eration of invariants and intermediate assertions. Theo- 
retical Computer Science, 173(1):49 — 87, 1997. 

[8] F. Bourdoncle. Efficient chaotic iteration strategies with 
widenings. hi D. Bj0rner, M. Broy, and I. V. Pottosin, 
editors, Proceedings of the International Conference on 
Formal Methods in Programming and their Applica- 
tions, pages 128-141, 1993. Vol. 735 of Lecture Notes 
in Computer Science, Springer- Verlag. 

[9] M. Bozga, J. Fernandez, A. Kerbrat, and L. Mounier. 
Protocol verification with the Aldebaran toolset. Soft- 
ware Tools and Technology Transfer journal, 1998. 

[10] M. Bozga, J.-C. Fernandez, L. Ghirvu, S. Graf, 
J. Krimm, and L. Mounier. IF: An Intermediate Repre- 
sentation and Validation Environment for Timed Asyn- 
chronous Systems. In Proceedings ofFM’99, Toulouse, 
France, LNCS, 1999. 



[11] E. Clarke, E. Emerson, and E. Sistla. Automatic verifi- 
cation of finite state concurrent systems using temporal 
logic specifications: A practical approach. In 10th ACM 
symp. of Prog. Lang. ACM Press, 1983. 

[12] E. Clarke, O. Grumberg, and D. Long. Model check- 
ing and abstraction. ACM Transactions on Programming 
Languages and Systems, 16(5), 1994. 

[13] D. Dams. Abstract interpretation and partition refine- 
ment for model checking. PhD thesis, Technical Univer- 
sity of Eindhoven, 1996. 

[14] D. Dams, R. Gerth, and O. Grumberg. Abstract in- 
terpretation of reactive systems: Abstractions preserv- 
ing ACTL*, ECTL* and CTL*. In Proceedings of the 
IFIP WG2 . 1IWG2.2IWG2 .3 (PROCOMET). IFIP Trans 
actions, North-Holland/Elsevier, 1994. 

[15] C. Daws, A. Olivero, and S. Yovine. Verifying ET- 
LOTOS programs with KRONOS. In Proc. FORTE’94 , 
Beme, Switzerland, Oct. 1994. 

[16] M. B. Dwyer and I. Hatcliff. Slicing software for model 
construction. In Proceedings of ACM SIGPLAN Work- 
shop on Partial Evaluation and Semantics-Based Pro- 
gram Manipulation (PEPM’99), Ian. 1999. 

[17] J.-C. Fernandez, C. lard, T. leron, L. Nedelka, and 
C. Viho. Using on-the-fly verification techniques for the 
generation of test suites. In R. Alur and T. A. Henzinger, 
editors, Proceedings of the. 8th International Confer- 
ence on Computer-Aided Verification (Rutgers Univer- 
sity, New Brunswick, NJ, USA), volume 1102 of LNCS. 
Springer Verlag, 1996. Also available as INRIA Re- 
search Report RR-2987. 

[18] V. Ganesh, H. Saidi, and N. Shankar. Slicing SAL. Draft, 
1999. 

[19] S. Graf and H. Sa'idi. Construction of abstract state 
graphs with PVS. In Conference on Computer Aided 
Verification CAV’97, LNCS 1254, Springer Verlag, 
1997. 

[20] N. Halbwachs and D. Peled, editors. Computer-Aided 
Verification, CAM ’99, volume 1633 of Lecture Notes in 
Computer Science, Trento, Italy, luly 1999. Springer- 
Verlag. 

[21] R. Kurshan. Computer-Aided Verification of Coordinat- 
ing Processes, the automata theoretic approach. Prince- 
ton Series in Computer Science. Princeton University 
Press, 1994. 

[22] D. E. Long. Model Checking, Abstraction, and Compo- 
sitional Reasoning. PhD thesis, Carnegie Mellon, 1993. 

[23] G. Liittgen and V. Carreno. Analyzing mode confusion 
via model checking. In D. Dams, R. Gerth, S. Leue, 
and M. Massink, editors. Theoretical and Practical As- 
pects of SPIN Model Checking (SPIN ’99), volume 1680 
of Lecture Notes in Computer Science, pages 120-135, 
Toulouse, France, September 1999. Springer- Verlag. 

[24] Z. Manna and A. Pnueli. Temporal Verification of Reac- 
tive Systems: Safety. Springer- Verlag, 1995. 

[25] K. McMillan. Symbolic model checking. Kluwer Aca- 
demic Publishers, Boston, 1993. 

[26] C. Munoz and J. Rushby. Structural embeddings: Mech- 
anization with method. In Proceedings of the World 
Congress on Formal Methods FM 99, volume 1708 of 
LNCS, pages 452-471, 1999. 


[27] S. Owre, I. Rushby, N. Shankar, and F. von Henke. For- 
mal verification for fault-tolerant architectures: Prole- 
gomena to the design of PVS. IEEE Transactions on 
Software Engineering, 21(2): 107-125, Feb. 1995. 

[28] I. P. Queille and J. Sifakis. Specification and verification 
of concurrent systems in CESAR. In Proc. 5th Int. Sym. 
on Programming, volume 137 of LNCS, pages 337-351. 
Springer- Verlag, 1982. 

[29] H. Sa'idi. Modular and incremental analysis of concur- 
rent software systems. In 14th IEEE International Con- 
ference on Automated Software Engineering, Oct. 1999. 

[30] H. Sa'idi and N. Shankar. Abstract and model check 
while you prove. In Halbwachs and Peled [20], pages 
443^154. 

[3 1 ] The SAL Group. The SAL intermediate language. Avail- 
able at: http : / / sal . csl . sri . com/, 1999. 



REPORT DOCUMENTATION PAGE 

Form Approved 
OMB No. 0704-0188 

Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data 
sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other 
aspect of this collection of information, including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and 
Reports, 1 21 5 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302, and to the Office of Management and Budget, Paperwork Reduction Project (0704-0188), 
Washington, DC 20503. 

1 . AGENCY USE ONLY (Leave blank) 2. REPORT DATE 3. REPORT TYPE AND DATES COVERED 

June 2000 Conference Publication 

4. TITLE AND SUBTITLE 

Lfm2000: Fifth NASA Langley Formal Methods Workshop 

5. FUNDING NUMBERS 

WU 519-50-1 1-01 

6. AUTHOR(S) 

C. Michael Holloway, Compiler 

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 

NASA Langley Research Center 
Hampton, VA 23681-2199 

8. PERFORMING ORGANIZATION 
REPORT NUMBER 

L-17985 

9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 

National Aeronautics and Space Administration 
Washington, DC 20546-0001 

10. SPONSORING/MONITORING 
AGENCY REPORT NUMBER 

NASA/CP-2000-210100 

11. SUPPLEMENTARY NOTES 

12a. DISTRIBUTION/AVAILABILITY STATEMENT 

Unclassified-Unlimited 

Subject Category 61 Distribution: Standard 

Availability: NASA CASI (301) 621-0390 

12b. DISTRIBUTION CODE 

13. ABSTRACT (Maximum 200 words) 

This is the proceedings of Lfm2000: Fifth NASA Langley Formal Methods Workshop. The workshop was held 
June 13-15, 2000, in Williamsburg, Virginia. See the web site <http://shemesh.larc.nasa.gov/lfm2000/> for 
complete information about the event. 

14. SUBJECT TERMS 

Formal Methods, Software Engineering, Proof, Model Checking, Safety 

15. NUMBER OF PAGES 

209 

16. PRICE CODE 

A10 

17, SECURITY CLASSIFICATION 
OF REPORT 

Unclassified 

18. SECURITY CLASSIFICATION 
OF THIS PAGE 

Unclassified 

19. SECURITY CLASSIFICATION 
OF ABSTRACT 

Unclassified 

20. LIMITATION 
OF ABSTRACT 

UL 


N5N 7540-01-280-5500 Standard Form 298 (Rev. 2-89) 


Prescribed by ANSI Std. Z-39-18 
298-102 

























